Login

Recent searches

No recent searches

Search options

Not available on mastodon.xyz.
mastodon.xyz is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Mastodon instance, open to everyone, but mainly English and French speaking.

Administered by:

Server stats:

824
active users

mastodon.xyz: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.4

Public
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.

Public
pwm
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.
Public
Alex Gleason

@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.

GitLabSoapbox / Nostrverse · GitLabEarly prototype of Mastodon API on Nostr (WIP!!)
JC Brand

@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.

Mar 14, 2023, 02:34 PM·Public·Web
0boosts·1favorite
Public
JC Brand

@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.

Public
JC Brand

@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.

Public
JC Brand

@alex @3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922

Sorry, just to clarify.

If done right, it actually doesn't break compatibility with vanilla XMPP clients, it just means you can't use vanilla XMPP clients to send messages to the Nostr network.

But vanilla clients could read such messages if they include corresponding XMPP payload data so that vanilla XMPP clients understand that part while ignoring the Nostr data.

ExploreLive feeds
About