Who is at fault here? The client that follows the spec, or the client that uses a non-standard protocol feature?

Here's a different way to ask the same question:

Who is at fault here? The client that solves a user problem by creating a bespoke protocol addition, or the client that fails to respect it?

nostr:nevent1qywhwumn8ghj7mn0wd68ytndw46xjmnewaskcmr9wshxxmmd9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcppemhxue69uhkummn9ekx7mp0qyfhwumn8ghj7ur4wfcxcetsv9njuetn9uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uq3jamnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kz7qg3waehxw309ahx7um5wgh8w6twv5hsz8rhwden5te0vf6kx6m9wshxxmmjv93kcefwwdhkx6tpdshsqg99v3ykukd5ccp2gn5wnw29whcmqwvc82qznphczunzc5um7s3c2qz0wsws

Reply to this note

Please Login to reply.

Discussion

Who is at fault here? The client that deletes stuff it doesn't support/understand or the client that uses nostr in non-standard ways?

So Coracle stores relays one way. If it doesn't find relays that way, it should probably set default relays its way. The destruction probably happened when nostr:npub1vp8fdcyejd4pqjyrjk9sgz68vuhq7pyvnzk8j0ehlljvwgp8n6eqsrnpsw added a follow or something, not when editing the relays.

Yeah a client could have custom features that it uses in profile data, mute lists (expiry), contact list (pet names) etc. just because your parser doesn’t take those into consideration and nukes things, that can only be true for a specific point in time. What happens when new things are spec’d and you don’t update your code in time? Then your client would be nuking things even when you thought you were doing everything right.

The only way to be as friendly as possible to the network is to accept things liberally, don’t delete stuff. I am not optimistic of clients devs actually caring about this so I am resorting to “healing” damage from other clients automatically.