I can already say now, that this change, will make the situation much worse than it already is.
Adding complexity to the protocol, with the introduction of data fragments like this, will create a whole set of other issues.
Each app should simply keep a backup of the following list, perhaps a historical backup and potentially some merge functionality. That's enough to mitigate this problem, doesn't need added protocol complexity.
Login to reply
Replies (2)
That's not any less complex, and doesn't solve the case where a user visits a new app that is poorly coded. In my PR, well-written apps can protect users against poorly-written apps
All backends must be updated.
All frontends must be updated.
This will be more complex, you will have clients that suddenly supports way more following list than standard kind 3, what then? You have massive fragments between the apps that the user uses.
How does one choose which of the thousands of following to keep in sync with the legacy kind 3?
There are so many potential scenarios that is problematic already today, this introduced its own set of scenarios that must be handled and mitigated, not just by frontends, but also backends.
My notification service will now need to listen to both kind 3 events, and to multiple 33000, and have some advanced logic other than: "send notification to the last pubkey added to the list".
I get the wish for this, but I'd rather not extend existing patterns with even more complexity, if it doesn't really bring a whole lot of benefits that makes it a no-brainer.