quotingI think we are further along outbox implementation than we are being given credit for:
nevent1q…n545
1. When onboarding new users, Primal ensures that the default set of relays includes a combination of larger relays and “long tail” smaller relays. We are already contributing to the spread of content over the entire public relay infrastructure. In contrast, Damus uses the same 4 relays for all new users.
2. We leave relay hints in all user and event mentions, as well as “copy id” actions, so that outbox clients can find things.
3. By default, all Primal clients write directly to the outbox relays the user has specified.
Therefore, when it comes generating content on the network, Primal already does all the right things. Please correct me if I’m missing something.
What remains to be done is the ability to diversify ways of reading/discovering content. We can’t solely rely on the caching service; our clients need to be functional without it. We are working on it.
As for the “Primal isn’t a real Nostr client” claim, that's a bad look jb55 (nprofile…2ln2). Let’s focus on building. Damus still needs proper outbox and blossom support. Maybe that’s where energy is better spent instead of fudding another project.
Joe on Nostr: Curious what do you think of this? If Primal is supporting outbox on the write side ...
Curious what do you think of this? If Primal is supporting outbox on the write side this way (obviously not on the read side) how do you feel it helps or does not help with the dilemma?