nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qgnwaehxw309ac82unsd3jhqct89ejhxtcppemhxue69uhkummn9ekx7mp0qyxhwumn8ghj7e3h0ghxjme0qqsp0c5gn7aqzqsaqj9p8lgt5yy26vwrsvnzj4rqcg0xn3pl4ra729gznathl what do you think of publishing that on Nostr so we can comment on it better?

I agree with everything you said, it's very similar to what many of us have been arguing for for years. You'll find the discussions if you search for "outbox model".

I just don't agree with the DM bit. NIP-17 should be followed as it is better solution. But this is a minor point and almost unrelated to the core of your article.

Reply to this note

Please Login to reply.

Discussion

Thanks fiatjaf! I can do that, I just need a decent article editor for Nostr that does remote signing. I could capitulate and use extension or nsec though. I'll look more into that later.

To respond to the last part first, the DM part is not that important, though I still believe it's the right way to go: Publish DMs to me to my full relay list, then my relays should have auth implemented to only return DMs to me, nobody else. That simplifies a lot for implementors and users, it simplifies backups, data management and great deal of other things. This is one of the best parts of NIP-17:

"It's advisable that relays do not serve kind:1059 to clients other than the ones tagged in them.". Maybe I will implement support for kind 10050, but I doubt it. I seriously think it's a really bad idea to have separate relays for DMs and Group Chats.

My thoughts is based of the outbox model, but removing the more too complex ideas in NIP-65 and the current discussions around changes to the standard. I'm taking the ideas from DWN and Solid (pods) to Nostr, attempting to solve the scaling issue (avoiding large popular relays), and also the discovery part, where resolving DID Documents to get the services of the identifier (public key), which is the most important aspect to ensure scaling.