I think nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c will love this
Discussion
Just added his pubkey too! Let me know who else I’m missing. I sent a DM to nostr:npub1dww6jgxykmkt7tqjqx985tg58dxlm7v83sa743578xa4j7zpe3hql6pdnf and nostr:npub10td4yrp6cl9kmjp9x5yd7r8pm96a5j07lk5mtj2kw39qf8frpt8qm9x2wl as well and added their pubkeys too.
May I ask a few questions? If all REQs require AUTH, and somebody wants to send me a kind-1 reply, you accept the AUTH even if you don't know them? Or sorry, you don't take kind-1? If I make it an inbox relay, people will try to put all kinds of inbox events there, and you will only take some of those? Or do you accept it all and only allow the p-tagged person to read the ones of the kinds you listed?
I think an inbox needs to accept anything tagging the authorized users, of any kind, but only allow the authorized tagged user to read those back. Then no content needs to be moderated because only the recipient can see it. In my inbox design, I would also accept and serve 10002 from everybody just to promote that, but it's not necessary.
This initial design is to focus only on events that need read protection. I get generically the idea of everyone running their own inbox relay that accepts all the posts tagged to them but that is not what I’m trying to achieve here and I don’t see what advantage there is to reading a kind 1 from this relay vs any public one.
All REQs require AUTH but writing events does not. As long as the tagged user in the event has an active inbox, the event will be written to the relay. Since as you mentioned no content is moderated in this approach, I added a special use of kind 1984s to treat spam reports as delete requests that are automatically honored by the relay as long as the user reporting the event is the user tagged in the event. This allows you to treat the relay like a personal inbox and simply delete messages “sent” to you even though you are not the author.
Ok the problem here is that if I specify that relay as my 'read' relay, clients will send kind-1 events and they will fail. Then I wont get that event at all. Most clients don't fail over to the next read relay. There is no way I can tell people per-event-kind which relay to use.
Why not? You can standardize these things in the NIP -- either in NIP-65 or somewhere else --, then add a marker that is not "read" but "dm", for example, and have DM clients send DMs to those DM specific relays.
I do think a designated relay for “private” events would be useful.
For what it’s worth, I’m happy to also build truly “individual” inbox relays that accept all kinds and work exactly as you have in mind nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c but I don’t expect many users to run their own. If they did, I have to assume speed and uptime would be poor on average making the client experience worse for everyone. I guess I’m not totally sold on the tradeoffs, personally.
We could offer it as a paid service (where we host them), but then are we really accomplishing anything by doing so?
Do we have a PR on NIP-65 to add a 'dm' relay where we specify the kinds of events? If not we should open it and start the debate
Ok sure we can do that. We haven't done it yet. So this is just for expermentation then at present?
Interesting, I will try it out
