mleku on Nostr: it could also have an index to compress it down but i don't think that the benefit ...
it could also have an index to compress it down but i don't think that the benefit would be that great being that most people have no more than about 15 and it's just a URL not a whole 32 bytes
i already have built an interface that could potentially enable relays to fan out requests to other relays where the relay operator has signed up the relay key to auth and distribute the events more easily while reducing bandwidth costs
also, yes, all events need to be stored with their signature, there isn't a practical benefit to not doing so
as it is, also, the compact encoding i created for realy, which is just the canonical encoding with the 64 bytes signature in raw binary form, is - yes, half the size of the raw JSON data in the database, and it's the highest entropy data in the protocol so it is good to be able to squeeze it 50% so easily.
and also, signed relay lists provide read and write relays for nip-65 in/outbox which is crucial to improving decentralization
in fact it reminds me that there is a case for an exception to the relay whitelist - where a user queries for a - such as DM or similar event via a pubkey they are looking for messages that tag their authed pubkey with... i have the directory one that filters down unauthed users reqs to provide those events to any and all, this is another case that could benefit from special handling on the read side, i wouldn't want to allow write access this way but read access would help mitigate some of the issues of poor outbox implementations in clients, or partitions between two users due to various possible other reasons that interfere with p2p messaging in particular
bah, too many things to think about
anyway, this feature i'm making doesn't touch relay lists directly, relay lists are just aggressively searched for and their relay URLs are tried randomly to achieve more consistency of events that are helpful to both UI/UX and web of trust purposes
i already have built an interface that could potentially enable relays to fan out requests to other relays where the relay operator has signed up the relay key to auth and distribute the events more easily while reducing bandwidth costs
also, yes, all events need to be stored with their signature, there isn't a practical benefit to not doing so
as it is, also, the compact encoding i created for realy, which is just the canonical encoding with the 64 bytes signature in raw binary form, is - yes, half the size of the raw JSON data in the database, and it's the highest entropy data in the protocol so it is good to be able to squeeze it 50% so easily.
and also, signed relay lists provide read and write relays for nip-65 in/outbox which is crucial to improving decentralization
in fact it reminds me that there is a case for an exception to the relay whitelist - where a user queries for a - such as DM or similar event via a pubkey they are looking for messages that tag their authed pubkey with... i have the directory one that filters down unauthed users reqs to provide those events to any and all, this is another case that could benefit from special handling on the read side, i wouldn't want to allow write access this way but read access would help mitigate some of the issues of poor outbox implementations in clients, or partitions between two users due to various possible other reasons that interfere with p2p messaging in particular
bah, too many things to think about
anyway, this feature i'm making doesn't touch relay lists directly, relay lists are just aggressively searched for and their relay URLs are tried randomly to achieve more consistency of events that are helpful to both UI/UX and web of trust purposes