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.