melvincarvalho on Nostr: I dont disagree. This is what TimBL refers to as client/client standards, which is ...
I dont disagree. This is what TimBL refers to as client/client standards, which is what we tried to build into Solid. The client/client standards suffer from the weakness that first movers get an advantage and that technical debt gets ossified quickly. 2+ different key management solutions (which is where we're heading btw) would indeed be indistinguishable from a fork for the end user perspective. The NIPs are a bit of a war zone, too centralzied, and it's hard to get people to agree on something. So we are going to have this problem in any case. If you zoom out, though, there are likely to be a first gen of clients, and a next gen of clients. Subkeys are a simple non intrusive addition. Just add a subkey array to your profile or to your nip-05, and then use that key, and signal to clients provably that it's part of your master key. Those that accept it can, those that dont want to, dont have to. IMHO the only way to do it is a full solution that has full version control anchored in the time chain, but we are a long way from that. Not just nostr, every social project needs this.
Published at
2024-07-06 06:40:22Event JSON
{
"id": "df5a36581e9652f648c94fa377ac6fddad77f9f22a9e716349cf332fe956ec39",
"pubkey": "de7ecd1e2976a6adb2ffa5f4db81a7d812c8bb6698aa00dcf1e76adb55efd645",
"created_at": 1720248022,
"kind": 1,
"tags": [
[
"e",
"212702ad022b48985734091df754d09607997e2abece53003a88332bbe675d8c",
"wss://relay.nostr.bg/all",
"root"
],
[
"e",
"01e2c6f997aa173f035cf8c910c5f5a8295f86cd58f2dcf282fd1330c4ec7d8d",
"wss://relay.nostr.bg/all",
"reply"
],
[
"p",
"de7ecd1e2976a6adb2ffa5f4db81a7d812c8bb6698aa00dcf1e76adb55efd645"
],
[
"p",
"577de06dce160a0379163a4bb7b680be3e0a0e1c68de6e6ba8c01134b44064dd"
]
],
"content": "I dont disagree. This is what TimBL refers to as client/client standards, which is what we tried to build into Solid. The client/client standards suffer from the weakness that first movers get an advantage and that technical debt gets ossified quickly. 2+ different key management solutions (which is where we're heading btw) would indeed be indistinguishable from a fork for the end user perspective. The NIPs are a bit of a war zone, too centralzied, and it's hard to get people to agree on something. So we are going to have this problem in any case. If you zoom out, though, there are likely to be a first gen of clients, and a next gen of clients. Subkeys are a simple non intrusive addition. Just add a subkey array to your profile or to your nip-05, and then use that key, and signal to clients provably that it's part of your master key. Those that accept it can, those that dont want to, dont have to. IMHO the only way to do it is a full solution that has full version control anchored in the time chain, but we are a long way from that. Not just nostr, every social project needs this.",
"sig": "580e0e5efa69c2eccc1295d182199fae1adb949b2d85cc8130f42321a16d00921a73a4ee7a193136f99c04d2bc32d0fbfeb13320e7915a6a01dfaceddcec0672"
}