Users must pick relays. But users don't know "by which criteria" they should pick them. So I scoured >1000 relays and picked about 25 open relays that don't require AUTH or payment and so they work for inbox and outbox for new people. When you use gossip for the first time and set up an account, these are the relays it lists for you to pick from. I am not associated with any of them, they just passed the tests. ALSO, inside gossip's relay panel for any particular relay, you can press "TEST" and it will do some tests and then let you know if the relay works as an inbox or outbox for you.... so that if it doesn't, you'll know to not add it to your relays list. There has been a push among the most prominent nostr developers to make more and more custom kinds of relays. Most of those don't work as inbox/outbox relays so we are in this situation where regular users are both required to choose relays for their kind-10002 relay list, but also that they have no idea how to do it and even if they knew how, don't have the tools or information necessary to make good choices.

That is also a main issue. Syncing would be useful.

I mean for picking your own relay. I'm not judging other peoples choices, but if their relays don't take my reply then that's their problem.

If there are tweaks that make it better for Reticulum, let me know. I've been busy in the fiat mines and spending a lot less time on nostr and mosaic both. But I'm not in a hurry, I think more time and more thought up front will make a more robust protocol in the end. I just moved the signature to the end of the record so that in the future it can be of any size, but I didn't create support for multiple cryptosystems yet. That can come later. Next I need to build out the reference implementations (server, client, offline tool).

Yes it is a deep change. I think one of the biggest problems is the infinite-redundancy issue. Most protocols have no redundancy. We have unbounded lists of relays. I think 3 is plenty for any particular purpose. Given how many connections we already have to make, it is just too onerous to connect to all 37 of someone's outbox servers. If people want to list 37 outbox servers, clients should use the first 3 and optionally use more if those 3 are down, but beyond the first 3 nothing is guaranteed. Not every client needs to help users setup their relay lists direclty, they can pass users over to a different client or website that does it.

I don't like blacklists here because that becomes another point of trust. I'd prefer to know for myself if a relay never works for me. So I want the client to do this and to remember.

Gossip client keep statistics on how successful a relay has been, and has fairly aggressive timeouts for poor performing relays. Also, for choosing outbox relays I go through a fairly long process to find appropriate relays and then I hardcode them in the next release. This goes like this: 1. Print out the relays from my gossip client sorted by rank (best performing first) 2. Skip if we never connected to it 3. Skip if the URL has a path beyond the hostname 4. Skip if the relay does not have a nip-11 5. Skip if the pubkey in the nip11 is invalid (or a prefix) 6. Skip of nip-11 indicates limitation.restricted_writes 7. Skip if nip-11 indicates fees 8. Remove relays known to be special-purpose 9. Score according to a custom algorithm that uses statistics from gossip client (number of attempts, last connected, success rate, etc). 10. test with a random keypair to see if it accepts a note and I can read it back. Fewer and fewer relays pass this gauntlet because of spam filtering measures.

Gossip isn't doing it. I think the idea was that any url ending in enough hex digits might be blossom and to do that. But I never got around to it, and I've become busy with things outside of nostr, at least for a while.

Your Casio calculator can't handle the truth about 2^256

1 in 115792089237316195423570985008687907853269984665640564039457584007913129639936

Why not just overwrite it again? Is it because the content of the previous one isn't accessible and so you can't see what you lost?

Ok, maybe Mike died and I'm wrapping up his estate.

Life has been busy recently. But I'm still alive. This note proves it.

Sorry for the delay in reply. There should be such a group or space. Right now it's just github, and occasional nostr threads like this. Mostly I wanted to get a fully functional proposal as a starting point, and then draw in the community, even if my proposal was shredded and a lot of the work wasn't used, because it isn't wasteful to become very familiar with the territory. But steer me now if you think I'm off course. I'm currently working on trying to support multiple cryptosystems at the master key level, especially so nostr events can be wrapped into Mosaic events, but also to eventually support post-quantum signature schemes. This means the signature might not be 64-bytes so I have to move it to the end of the record. Record flags will indicate the cryptosystem of the keys (master/signing). Within things like 'address' you just won't know the cryptosystem but it shouldn't matter since it's only used for signature verification. The mosaic-core code will have to deal with different kinds of keys, signatures, and restructure the record code. It's a big set of changes that I don't want to push out half-baked code (yet I already did some), but I've also not had time to devote to it recently. So anyhow, that is what is up atm.