dpc on Nostr: I was thinking about nostr, a bit from a similiar perspective, especially that a lot ...
I was thinking about nostr, a bit from a similiar perspective, especially that a lot of things are very much like in https://github.com/crev-dev/cargo-crev (exchanging documents signed by self-generated identities). The purpose was different, but most things are analogous.
Agreed on everything, but with a note that ease of building client is a huge benefit, especially for a protocol that lives or dies based on network effect. The idea would probably not catch on if building things would require too much work. If it is to be more complex, it needs to come with good off-the-shelf libraries to use.
End user software delivery is the biggest constrain on boostraping. Being able to handle everything from a web-client (primarily) is a must have. And it must work well.
The transport layer is a secondary thing. Self-signed document can be delivered in various ways - through web sockets, raw tcp, bittorrent, with e2e encryption or without it. In carg-crev github repositories are used free and public transport. Relays could support combination of all and it can be iterated on. So I would leave websocket with TLS as is to start with.
Using faster and more compact encoding and crypto, detaching the signature (witness) would be the biggest wins, and can't be easily iterated on after the fact, so getting it right is important. Good engineering suggest using some "one byte-prefix for version", to allow ecosystem rotate to something else in the future.
Identities/crypto should be modular (just add a "type" prefix). Clients that don't support certain ID type, can just ignore the message. That gives an ability to rotate to something else in the future, without changing too much elsewhere. I'm not a fan of GPG/SSH (even though I use them all the time, every day). Being able to support it for clients that need it for something - great. Forcing on everyone - meh. Something that is fast and easy to support would be a preferable default.
Also, IMO, nostr needs to come with a portable, reference WoT handling library. Coming up with a well working WoT is quite complex. Different clients could come up with their own approach, but having something off the shelf that clients can use to get a reasonable and consistent WoT behavior would be a big plus.
In cargo-crev there's a `crev-wot` https://github.com/crev-dev/cargo-crev/tree/master/crev-wot that implements a basic Wot based on "trust levels", "distance from root" with support for bans and overrides, but I always wanted to (and never had time) to implement "maximum flow" algorithm to deal with sybil attacks and bot farms.
Agreed on everything, but with a note that ease of building client is a huge benefit, especially for a protocol that lives or dies based on network effect. The idea would probably not catch on if building things would require too much work. If it is to be more complex, it needs to come with good off-the-shelf libraries to use.
End user software delivery is the biggest constrain on boostraping. Being able to handle everything from a web-client (primarily) is a must have. And it must work well.
The transport layer is a secondary thing. Self-signed document can be delivered in various ways - through web sockets, raw tcp, bittorrent, with e2e encryption or without it. In carg-crev github repositories are used free and public transport. Relays could support combination of all and it can be iterated on. So I would leave websocket with TLS as is to start with.
Using faster and more compact encoding and crypto, detaching the signature (witness) would be the biggest wins, and can't be easily iterated on after the fact, so getting it right is important. Good engineering suggest using some "one byte-prefix for version", to allow ecosystem rotate to something else in the future.
Identities/crypto should be modular (just add a "type" prefix). Clients that don't support certain ID type, can just ignore the message. That gives an ability to rotate to something else in the future, without changing too much elsewhere. I'm not a fan of GPG/SSH (even though I use them all the time, every day). Being able to support it for clients that need it for something - great. Forcing on everyone - meh. Something that is fast and easy to support would be a preferable default.
Also, IMO, nostr needs to come with a portable, reference WoT handling library. Coming up with a well working WoT is quite complex. Different clients could come up with their own approach, but having something off the shelf that clients can use to get a reasonable and consistent WoT behavior would be a big plus.
In cargo-crev there's a `crev-wot` https://github.com/crev-dev/cargo-crev/tree/master/crev-wot that implements a basic Wot based on "trust levels", "distance from root" with support for bans and overrides, but I always wanted to (and never had time) to implement "maximum flow" algorithm to deal with sybil attacks and bot farms.