I'm not going to attempt to steel man my case here, because it wouldn't matter if I did. It's a fundamental issue that cannot resolved without nuking everything.
But it seems obvious to me that using...
Binary encoding is a violation of the laws of Unix.
I've also been pondering a related issue with addressable events. The use of NIP-19 bech32 entities eliminates human-readable information that devs, users, and search engines can all use — another example of why this is a law of Unix.
I'm on a middle ground here, for good reason. Just like the REQ/COUNT extension I built and the general concept behind [TMP](https://njump.me/nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpz4mhxue69uhhyetvv9ujummjd3ujuer9wchsqgz2f6nyd984hlynths6un90p0v557k5wksdttew77nxqc9whjy08sxggm0g), there are more compact formats that remain human-readable, making indexing and debugging simpler.
I spent a lot of time thinking about alternatives to the current JSON-encoded messages. The only thing required to make the transition — without backward compatibility problems — is to create a secondary listener that speaks a more approachable yet still plaintext format, and instead of just replicating the dumb query language, make a better one that is part of the new protocol encoding extension.
I would invite you to take a look at Orly, which I rearchitected fully to comply with DDD, meaning it would likely be fairly trivial work to add a more extensible endpoint for protocol extensions.
With Nostr, we have some issues with deprecation being difficult to socially coordinate, as well as actually ending the use of deprecated protocols — as we have with Bitcoin. The only way I see it working is if you make the extension's benefits enticing enough to get devs to actually implement on it.
Keeping the structures of the old ways also makes transition easier, as people can just refactor their queries to select the other protocol format if available but keep their code structurally identical. This enables them to extend their client code to adopt the new, better protocol without leaving them stranded.
I've also been pondering a related issue with addressable events. The use of NIP-19 bech32 entities eliminates human-readable information that devs, users, and search engines can all use — another example of why this is a law of Unix.
I'm on a middle ground here, for good reason. Just like the REQ/COUNT extension I built and the general concept behind [TMP](https://njump.me/nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpz4mhxue69uhhyetvv9ujummjd3ujuer9wchsqgz2f6nyd984hlynths6un90p0v557k5wksdttew77nxqc9whjy08sxggm0g), there are more compact formats that remain human-readable, making indexing and debugging simpler.
I spent a lot of time thinking about alternatives to the current JSON-encoded messages. The only thing required to make the transition — without backward compatibility problems — is to create a secondary listener that speaks a more approachable yet still plaintext format, and instead of just replicating the dumb query language, make a better one that is part of the new protocol encoding extension.
I would invite you to take a look at Orly, which I rearchitected fully to comply with DDD, meaning it would likely be fairly trivial work to add a more extensible endpoint for protocol extensions.
With Nostr, we have some issues with deprecation being difficult to socially coordinate, as well as actually ending the use of deprecated protocols — as we have with Bitcoin. The only way I see it working is if you make the extension's benefits enticing enough to get devs to actually implement on it.
Keeping the structures of the old ways also makes transition easier, as people can just refactor their queries to select the other protocol format if available but keep their code structurally identical. This enables them to extend their client code to adopt the new, better protocol without leaving them stranded.
1❤️1👍1🤔1