Should we write a guide of how to implement the outbox ("gossip") model? Is that a good idea? What should that guide contain? nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
Discussion
Yes. Need to all be on the same implementation page.
no, the outbox model benefits from competing implementations because we haven't figure out the best approach yet
Then figure out the best approach and implement that way so that we don't have interoperability issues.
an implementation would need to be incredibly stupid for interoperability to become problematic; the outbox model doesn't really suffer from issues like event nomenclature or formatting or stuff like that where how one client behaves affects other clients
Bookmarking for future use in case someone does something dumb. 😂
probably not
it's hard enough that whoever writes it better figure it out by themselves and now follow a guide
if they can't figure it out then just don't do it and use one of the out-of-the-box (get it?) implementations
Yes. Absolutely, yes.
It can serve as a starting point for new developers that want to implement more advanced features but aren't exactly sure how to do it off reading the NIPs alone. Sometimes you just need to be explained things differently to understand then, and I think a mini guide would be helpful.
As for what it should contain?
- Why the Gossip model?
- Short comparison of fixed relay list and (partially?) automated gossipped list
- The basics (which events, for what, with which content)
- A very minimal example to illustrate. Can be a shell script using JQ, really. All it needs to do is illustrate how it is supposed to work. Bluntly speaking, a dev with two braincells will be able to transpose this into their desired language and make it work. :)
Educational content is always welcome!
нет
I don't think so, I think the general idea is not too hard to understand, if your deep into the nips it should make sense
I don't feel like there is very much to say on the implementation front. NIP-65 that nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z and I rewrote pretty much sums it up from a "what you need to do" perspective.
There was prior stuff that gossip uses: Originally I peeked at Astral's/Damus's kind-3 contents. Then I suggested adding relays to nostr.json. Then I setup a historical record of anything that associated an author to a relay (such as an nevent, or recommended relay url). Then I learned about and added nprofile. Then we did NIP-65.
Gossip also does it's own relay ranking. A relay in someone's published kind-10002 would get 20 points, whereas a recommended relay url would get 1 point but only if it was recent, etc. Complex and ad-hoc.
And you think no one should do any of these things? I think you are terribly wrong. The "complex and ad-hoc" stuff are very important. NIP-05 hints are important, other hints are important. We can't rely on just NIP-65.
But in any case, how would you implement it if starting from scratch today?
OUTBOX MODEL
Motivation:
We don't all use the same relays. And from time to time we change which relays we use. In order to read the notes written by somebody, your client needs to find them. The outbox model is a straightforward way to do this.
Two types of relays:
In the outbox model, there are two kinds of relays: 'write' (or outbox) and 'read' (or inbox).
Write relays (outboxes):
Write relays (or outboxes) solve 90% of the problem as follows:
* When you create a note, write it to your outbox relays.
* When you want to read someone else's notes, read them from their outbox relays.
Read relays (inboxes):
If somebody tags you on a note, or sends you a DM, then the above won't work. Because maybe you don't follow them so you never read any of their notes from their outbox relays.
Read relays (of inboxes) solve this last 10% of the problem as follows:
* When you tag somebody in a note (including DMs), also write the note onto their read relays.
* Subscribe to your read relays for notes tagging you.
Relay lists:
In order for this scheme to work, people need to be able to lookup which relays another person uses. NIP-65 describes a kind-10002 event that people can use to publish which relays they use. These are suggested to be published to many relays so they can be found more easily.
How many relays?:
Some people have many outboxes. It is not necessary to read their notes from all of their outboxes. You only need to read them from one if that one relay is working and has all of their notes as it should. For redundancy and to be sure you aren't missing notes, you can choose instead to read from two of their outboxes. You could go higher, but for little additional benefit.
Following many people:
In order to follow many people, you may want to construct an algorithm tnat computes the smallest set of relays that covers everybody you follow twice (if you want two per person).
The gossip-relay-picker has an algorithm, but it is unlikely to be optimal and it remains an issue of research to come up with a better one.
When you do connect to these relays, it is important not to subscribe to everybody on every relay, but only to create the subscriptions you need in order to get one or two relays per person you follow.
Dealing with users who have not published a kind-10002 relay list:
Many clients do not support NIP-65. For users who have not published a relay list, there are a number of ways you can use to try to determine where they post. These include:
* The NIP-05 nostr.json file may contains relays for a user.
* An 'nprofile' object contains relays for a user
* kind-3 Contact List contents sometimes contain relay information (Astral and Damus did this, as well as probably some other clients)
* An 'nevent' contains relays, and the event itself has an author, which can be associated.
* Some tags have a 'recommended_relay_url' which associate a note with a relay. That note's author can then be associated to that relay.
* Clients can give users the ability to manually associate relays with people.
When a client encounters any of the data above, it should make an association between the user and the relay and remember how it learned that association, and perhaps also when it learned that assocation. That data is important for scoring the relevance of the association when determining what are the best relays to use for the person.
Then the best relays for a person can be chosen by an algorithm that sorts through those associations.
maybe mention it more in other nips, so it's importance is more obvious
Guides are great. Making accommodations demonstrates strength not weakness— learning styles.
Yes please.
I would love to learn more about nostr