Conversation

Notices

1. Embed this notice
   fiatjaf (3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d@mostr.pub)'s status on Thursday, 16-Mar-2023 22:40:09 JST fiatjaf

   • Alex Gleason
   @alex can you see a future in which fediverse servers act as natural Nostr relayclients for their users?
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Thursday, 16-Mar-2023 22:40:09 JST Alex Gleason

     in reply to

     @3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d Yes, the tricky thing being that we have to store their private keys. I’m still working through it in my head.

   • Embed this notice
     Ruq (ruq@seal.cafe)'s status on Thursday, 16-Mar-2023 23:19:51 JST Ruq

     in reply to

     • Alex Gleason

     you mean public keys…right?

   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Thursday, 16-Mar-2023 23:19:51 JST Alex Gleason

     in reply to

     • Ruq

     @Ruq @3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d How else would you do scheduled posts? Mastodon API itself also wants your private key.

   • Embed this notice
     fiatjaf (3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d@mostr.pub)'s status on Friday, 17-Mar-2023 00:12:09 JST fiatjaf

     in reply to

     • Alex Gleason
     What is the problem of servers storing their private keys? In the current world they already fully control users' identities anyway.
   • Embed this notice
     fiatjaf (3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d@mostr.pub)'s status on Friday, 17-Mar-2023 00:12:09 JST fiatjaf

     in reply to

     • Alex Gleason
     https://minds.com/ proposed NIP-26 because they didn't want to have full control over users' keys, but I am still confused about what exactly they wanted to do with that. I was thinking about a process through which a hosted key slowly signals that it is in fact an "adopted child" of some parent key created elsewhere, then readers can slowly migrate to following that other key. This could be done with NIP-26 but that is not necessary even, there could be just a pointer and a hint. Is there a problem with this?
     Alex Gleason likes this.
   • Embed this notice
     fiatjaf (3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d@mostr.pub)'s status on Friday, 17-Mar-2023 00:12:09 JST fiatjaf

     in reply to

     • Alex Gleason
     There is another idea here that could be harnessed for this purpose: follow recommendations. Instead of saying "follow this person" and linking to their profile one can send a special kind or tag that tells the client to render a button the user can click to follow that person. Clients may cache these recommendations and show them in a sidebar, like Twitter does. Crowdsourced follow recommendations.
     Alex Gleason likes this.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Friday, 17-Mar-2023 00:54:44 JST Alex Gleason

     in reply to

     @3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d The reason for NIP-26 is to retrofit Nostr into a previously centralized system. Even ActivityPub servers are centralized compared to Nostr.

     This is good for Nostr because it expands the userbase. The most valuable asset of a social network is the userbase, so each expansion increases its viability due to network effects. Part of the Nostr strategy SHOULD be getting legacy platforms (with a lot of users) to adopt the protocol.

     But if we store user’s private key on our server, it’s lose-lose. First of, WE don’t want that liability. A leaked private key is way worse than a leaked password because if that happens, we can’t regain control over the account. From the user’s perspective, they can’t trust a key that ever touched our server. But we WANT them to be able to migrate out. We want the best of both worlds: to give users the full freedoms of the Nostr protocol, AND all the conveniences of centralized platforms.

     I think ultimately it IS possible to offer high convenience on the Nostr protocol by building fancy relays, or making clients connect to special “aggregator” servers. Also, by offering hardware wallets and giving users flexible key schemes like NIP-41. But this is part of the new world, not part of the old one, and there is no simple path to bring those large existing centralized communities to Nostr.

     The problem NIP-26 solves is that it let’s us store a “private key” but limits damage from a leak. The user generates their own key and only submits a delegation string to us every ~30 days. If a breach happens, the damage is limited to ~30 days. Users can control and configure this depending on their desired level of security. Most importantly, it lets us retrofit Nostr into our system. It’s not perfectly elegant. But it’s a matter of whether you want to focus more on the new world, or try to bring the old world along with us. Personally is see great value in that.