<p>I like designing the DAO to allow for support of this feature eventually, as long as that future-flexibility does not increase current complexity too much. The idea of different DAOs being able to "talk to each other" by a generic ask-Bisq-Oracle feature by a user running full nodes for both DAOs does seem like it could be a very powerful idea, even if we can't completely visualize how such features would be used in the boundless future.</p>
<p>Re:</p>
<pre><code>There is a hard coded enumeration of such parameters and adding new ones is a hard fork.
All of those parameters (beside the BTC trade fee) has direct effects on BSQ/DAO consensus.
So we are not very flexible with that approach.
</code></pre>
<p>I believe if we changed the logic to handle unknown / higher valued enum values for the DAO parameters by assuming our code does not understand them, we could be able to support them as a soft fork, if at least majority of BSQ stakeholders upgraded to a version that does understand the new parameters. In such a case maybe we also want to hint to the user that they could be running an old release and can consider upgrading. (Protobuf allows this pseudo-forward compatibility already for new / higher-id fields, which are ignored by clients running old releases without knowledge of those fields.)</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/proposals/issues/33#issuecomment-407765831">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AkpZtlYgM0I3a2WYy5tapSaFRD4jIDctks5uKHsmgaJpZM4Vf130">mute the thread</a>.<img src="https://github.com/notifications/beacon/AkpZthGp_meiFbmQpiZ4wEnwv63WAYuRks5uKHsmgaJpZM4Vf130.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/bisq-network/proposals","title":"bisq-network/proposals","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/bisq-network/proposals"}},"updates":{"snippets":[{"icon":"PERSON","message":"@chirhonul in #33: I like designing the DAO to allow for support of this feature eventually, as long as that future-flexibility does not increase current complexity too much. The idea of different DAOs being able to \"talk to each other\" by a generic ask-Bisq-Oracle feature by a user running full nodes for both DAOs does seem like it could be a very powerful idea, even if we can't completely visualize how such features would be used in the boundless future.\r\n\r\nRe:\r\n```\r\nThere is a hard coded enumeration of such parameters and adding new ones is a hard fork.\r\nAll of those parameters (beside the BTC trade fee) has direct effects on BSQ/DAO consensus.\r\nSo we are not very flexible with that approach.\r\n```\r\nI believe if we changed the logic to handle unknown / higher valued enum values for the DAO parameters by assuming our code does not understand them, we could be able to support them as a soft fork, if at least majority of BSQ stakeholders upgraded to a version that does understand the new parameters. In such a case maybe we also want to hint to the user that they could be running an old release and can consider upgrading. (Protobuf allows this pseudo-forward compatibility already for new / higher-id fields, which are ignored by clients running old releases without knowledge of those fields.) "}],"action":{"name":"View Issue","url":"https://github.com/bisq-network/proposals/issues/33#issuecomment-407765831"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/proposals/issues/33#issuecomment-407765831",
"url": "https://github.com/bisq-network/proposals/issues/33#issuecomment-407765831",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [bisq-network/proposals] BSQ/DAO oracle (#33)",
"sections": [
{
"text": "",
"activityTitle": "**chirhonul**",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": "@chirhonul",
"facts": [

]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"bisq-network/proposals\",\n\"issueId\": 33,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\": \"bisq-network/proposals\",\n\"issueId\": 33\n}"
},
{
"targets": [
{
"os": "default",
"uri": "https://github.com/bisq-network/proposals/issues/33#issuecomment-407765831"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 360668660\n}"
}
],
"themeColor": "26292E"
}
]</script>