Conversation

Notices

1. Embed this notice
   Alex Gleason (alex@gleasonator.com)'s status on Tuesday, 14-Mar-2023 10:40:42 JST Alex Gleason

   Mostr bridge now publishes a Zap event to ActivityPub. You have to do Nostr stuff to valiadate it, but it’s a step.

   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Tuesday, 14-Mar-2023 14:07:34 JST Alex Gleason

     in reply to

     • pwm

     @3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922 I started on that here: https://gitlab.com/soapbox-pub/nostrverse

     I’m trying to change Soapbox minimally so it stays compatible with Mastodon and Rebased. But the main problem is signing events. Submitting a status isn’t the same as submitting an event. So what we can do is send the private key to the server (that’s how this demo works), but that isn’t a great solution. Another idea I had was to have the server send websocket “signature request” events to the client, then the client only has to implement event signing in one place. This is probably the cleanest solution, but clients will have to update to support it.

     As far as deduplication with the bridge, there’s already an issue to “opt out” of the bridge: https://gitlab.com/soapbox-pub/mostr/-/issues/26 Once implemented, hybrid AP/Nostr accounts should just opt-out.

     I’m less interested in building a hybrid backend than I am making Soapbox work with Nostr, tho.

   • Embed this notice
     pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Tuesday, 14-Mar-2023 14:07:35 JST pwm

     in reply to
     What I've been wondering, since a lot of nostr clients are big piles of webshit anyway, why not just graft a nostr client onto soapbox/pleroma fe? I think all the pieces are almost there and work required would mostly be on the frontend: backend: - write-only relay for instance users (if enabled) - backend endpoint for querying the nostr.json of the user (for nip-05 verification) - standardize and configure (via profile key/value fields or something) a users nostr pubkey frontend: - configurable list of relays for the nostr client, supplied by server, like FE settings - configurable nostr bridge as above - nostr client implementation, and all that entails (dense bullet point) The integration with pleroma/rebased backend to make the integration nicer is fairly minimal, the biggest part is definitely the nostr client implementation, but I suspect minimal libraries for this already exist. The biggest conceptual hiccup I see is that your posts would be double posted to nostr because of the fedi copy being bridged, after the nostr version is published. Without someway to automagically hide/deduplicate (possibly a protocol extension?), this would be yucky. Is this actually a bigger deal, and not just a hiccup, the reason bridging an identity is the most correct way to do it? I don't think it's absolutely impossible to unify or integrate the identities of users across nostr and AP, but the bridge disturbs me because of the need for the delegation NIP, and I haven't quite thought up a good way to do it somewhat natively via a unified nostr+AP client.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Tuesday, 14-Mar-2023 14:09:24 JST Alex Gleason

     in reply to

     • pwm

     @3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922 Another idea I had was to make the Nostr adapter work entirely in a Service Worker. It could work, but I’m not sure it’s better.

   • Embed this notice
     Melvin Carvalho (de7ecd1e2976a6adb2ffa5f4db81a7d812c8bb6698aa00dcf1e76adb55efd645@mostr.pub)'s status on Tuesday, 14-Mar-2023 20:45:06 JST Melvin Carvalho

     in reply to
     You are doing amazing work, @alex We might be at the point where we are starting to witness the next generation of fediverse clients AP could do with an upgrade, too
     Alex Gleason likes this.
   • Embed this notice
     pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Tuesday, 14-Mar-2023 20:48:58 JST pwm

     in reply to
     This is more or less what I was thinking about (assuming service worker is not Typescript for dedicated thread on the backend). Glom on an otherwise independent nostr client to the frontend, not the backend. Changing the soapbox backend as little as possible, and keeping all of the nostr things in a purely client-side JS nostr client. That way, you click submit, your post goes to the AP server, and your web-browser does all the nostr things. That would be why de-duplication would need to be addressed. Server-side things from the AP instance would then be limited to providing things like the appropriate response to NIP-05 requests, hosting and serving media, and possibly fancier things like verifying pubkey ids for things like zaps etc by saying yes, who ever has pubkey foo is lightning address bar, or however that actually works, as they all seem to rely on some third party server to do it. This way, the AP instance is that server, reducing reliance on things like nostr.build or void.cat in the case of media, etc. Providing a write-only relay for users of the instance would not be strictly necessary in this arrangement, just maybe helpful to the nostr network, a bonus so that you aren't swamping some other relay with all the otherwise fedi posts exclusively. Though, if it could leverage the same storage the AP server had, that would prevent double storing the message. I suppose once a message was signed, it could pass through the same post submission flow, and be accessible to the instance relay as though it had been submitted by any other client. Again, not strictly necessary since my original thought would be to have a pretty much independent nostr client in-browser, alongside the existing frontend code. Of course this increases client code footprint but I suspect that isn't something you are aggressively trying to minimize. The idea isn't to make soapbox receive nostr messages natively, the bridge does that, and I think it can stay that way(?). The more I've read what you've posted I think you want every soapbox instance to be like the mostr bridge, an AP server and a nostr client and I'm thinking perhaps most of the legwork can be done client-side, since that is how most of these web clients for nostr seem to work anyway. In some sense what you'd be doing is analogous to sending a text message, and an email, with the same content, just from the same text area and submit button. The email is signed by your client, but both are submitted to their respective networks separately. Fortunately through NIP-05 the email address and the phone number are already linked, in this analogy. That's the most straightforward path to some unified identity, if that's really the goal, or an appropriate/desirable one. I think it's not irreconcilable and that client-side requires the fewest hacks.
     Alex Gleason likes this.
   • Embed this notice
     JC Brand (jcbrand@mastodon.xyz)'s status on Tuesday, 14-Mar-2023 23:40:34 JST JC Brand

     in reply to

     • pwm

     @alex @3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922

     I've been researching and planning to write an XMPP-Nostr gateway and ran into the same issues and had similar ideas to you.

     The signing requirement makes Nostr incompatible with other protocols if you want the user to control their keys and your gateway to not know them.

     Alex Gleason likes this.
   • Embed this notice
     JC Brand (jcbrand@mastodon.xyz)'s status on Tuesday, 14-Mar-2023 23:40:43 JST JC Brand

     in reply to

     • pwm

     @alex @3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922

     Ultimately I came to the conclusion to drop the gateway and do something that I call Nostr-over-XMPP.

     Basically wrapping signed Nostr events inside XMPP messages.

     This breaks compatibility with vanilla XMPP clients, but you get some XMPP features to your Nostr account, like a contacts roster, nicknames, blocklists, message history etc.

     Alex Gleason likes this.
   • Embed this notice
     JC Brand (jcbrand@mastodon.xyz)'s status on Tuesday, 14-Mar-2023 23:40:45 JST JC Brand

     in reply to

     • pwm

     @alex @3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922

     Like you, I also thought about letting the XMPP-Nostr gateway send a "signing request" to the XMPP client so that the user can sign it. In the end, I decided against it, because the client *should* verify what it's signing, and if it does that, it actually understands Nostr and might as well construct the Nostr event itself, without the extra steps of a signing equest.