Notices by pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)
-
Embed this notice
pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Tuesday, 21-Mar-2023 11:07:14 JST 
pwm
The only tranny free zone left, apparently -
Embed this notice
pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Thursday, 16-Mar-2023 22:42:10 JST
pwm
> people who weren't going to use Rebased anyway You can just say trannies Alex, they already hate you. Akkoma is just shitty Pleroma for people who no longer have cocks. -
Embed this notice
pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Thursday, 16-Mar-2023 14:32:43 JST
pwm
> twitter post from %CURRENT_TIMESTAMP% >= %CURRENT_YEAR% > absolutely braindead thoughts splattered, still convulsing on a keyboard like so much gore No fucking shit -
Embed this notice
pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Thursday, 16-Mar-2023 07:44:35 JST
pwm
#[1] Cc @80f48f5e and sharivegas (don't have you here) but I think you are both qualified relay operators to contribute to this discussion -
Embed this notice
pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Tuesday, 14-Mar-2023 20:48:58 JST
pwm
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. -
Embed this notice
pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Tuesday, 14-Mar-2023 14:07:35 JST
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. -
Embed this notice
pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Thursday, 09-Mar-2023 13:00:07 JST
pwm
Planning to do verified via nip-05 only? I saw some discussion of that as a spam deterrence measure yesterday. -
Embed this notice
pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Thursday, 09-Mar-2023 03:23:31 JST
pwm
strfry uses lmdb, same stuff most crypto daemons use to store the blockchain. It's supposed to be quite good (haven't used it), especially since you aren't so much doing relational shit with it, just reliably storing data in blocks on disk. I believe it is what slapd uses btw, if you've ever used that. Iirc it was spawned from that project and grew into its own thing, so I don't reckon it sucks ass -
Embed this notice
pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Thursday, 09-Mar-2023 00:00:17 JST
pwm
mostr.pub only knows about the posts that have been sent to it. basically some nostr user has to follow a fedi account in order for it to let the server that fedi user is on that it would like to receive those. It's similar in reverse, a fedi user has to ask for the posts of a nostr user from the bridge in order for it to send them along. It won't do that unless it thinks there is a follower relationship established -
Embed this notice
pwm (3baabe4d008648b5438bfe3180e3d443cbc36478fbabb65007099a96a1c56922@mostr.pub)'s status on Wednesday, 08-Mar-2023 14:07:28 JST
pwm
no sugar added ketchup is as sweet as you need. Buy it or make it yourself. It's pretty easy.
All GNU social JP content and data are available under the