Guidance on soft fork avoidance

[bloated-devish]

I'm starting to see many CIPs where the proposed solutions would end up doing soft fork. Are there any general guidance on fork avoidance. This is different from a regular programming paradigm, where its not that big a deal to add new field, but may be a big deal in the blockchain world.

[tijno]

Yes this type of guidance would be great. If it does not exist would you be able to draft something as a starting point @bloated-devish

[omicreativedev]

I believe with clever coding, much could be done on the front end without the need for core changes. Still, I realize some things could add to protocol. I feel as though if a soft fork is going to benefit everyone to add a handful of awesome features that will improve growth across the board without damaging anyone's current business model, let's get the independent node operators and dapp developers on board completely with plenty of communication— I think they would be supportive. Avoiding a soft-fork just to avoid one isn't always sensible. I feel it's actually smart to make whatever shifts are needed to scale before we have thousands of nodes and dapps we don't even know about or know the owners of. I feel like right now we're in an awesome place where we still are able to know almost everyone making dapps and that run nodes. For instance:

just an example

• Choice of where value comes from (change diamonds or tip button)
• Baked in payloader with micro messages
• a modular embed support (to make it easier for nodes to add/remove services)
• block acceptance of markdown, html, code maybe with headers to allow front ends to easily filter out posts (if chosen)
  bla bla bla

Just my opinion that avoiding a soft fork just to avoid one isn't pro-scaling. Generally in blockchain we avoid them to avoid the chain from splitting off or avoid people getting pissed off. I don't think people will get pissed off by solving the things they're pissed off about.

just my two sense <3 in love and respect fully

[bloated-devish]

I believe with clever coding, much could be done on the front end without the need for core changes. Still, I realize some things could add to protocol. I feel as though if a soft fork is going to benefit everyone to add a handful of awesome features that will improve growth across the board without damaging anyone's current business model, let's get the independent node operators and dapp developers on board completely with plenty of communication— I think they would be supportive. Avoiding a soft-fork just to avoid one isn't always sensible. I feel it's actually smart to make whatever shifts are needed to scale before we have thousands of nodes and dapps we don't even know about or know the owners of. I feel like right now we're in an awesome place where we still are able to know almost everyone making dapps and that run nodes. For instance:

just an example

• Choice of where value comes from (change diamonds or tip button)
• Baked in payloader with micro messages
• a modular embed support (to make it easier for nodes to add/remove services)
• block acceptance of markdown, html, code maybe with headers to allow front ends to easily filter out posts (if chosen)
  bla bla bla

Just my opinion that avoiding a soft fork just to avoid one isn't pro-scaling. Generally in blockchain we avoid them to avoid the chain from splitting off or avoid people getting pissed off. I don't think people will get pissed off by solving the things they're pissed off about.

just my two sense <3 in love and respect fully

Here are some examples, where we are avoiding today to soft-fork, but I think we need to start worrying about ExtraData because of this decision.

1. member.cash for example today stores the block data in it.
2. submit post source - current idea is to put it in extra data.
3. extra notes for buy/sell of creator coin and transfer coin - there is a CIP by aikon that might use extradata.

@maebeam in another thread rightfully expressed concern about ExtraData blow up and I share her concern.

I think we as community may need to start thinking through a bit more on soft fork and not see this as a bad thing.
Alternatively, it may be possible to have soft-forks every few weeks (or whatever cadence) and align these changes. These make it straightforward for people to realize they can soft-fork with care and not find solutions circumventing soft forks.

At this point, I am more worried about ExtraData abuse than anything else.

[bloated-devish]

I wrote up some thoughts on ExtraData abuse mitigation: #49 (comment). Please let me know what you think in that thread.

[tijno]

Just thinking through this cip - should it not be in q&a category?