#[0] The pubkey for your relay contact (NIP-11) should be in hex format, could you update it?
https://github.com/nostr-protocol/nips/blob/master/11.md#pubkey
also #[1]
my client is kvetching, and the spec says hex
some relays only allow posts by users with nip-05 as a spam deterrence mechanism. I suspect it is a minority of nostr users who are not
a) using some webshit hosted client that has a backend doing nip-05 for them or
b) already have a server that they can statically host a json file from to do the same thing themselves, trivially.
The nip-05 spec is thoughtfully designed to allow people to do the latter, with little trouble especially if you are a developer type, or even just a self-hosting blogger and I would argue that it is more in keeping with the spirit of the thing, rather than centralization around a **brand** as certain, further up the reply chain, individuals are promoting.
The lovely part of being a non-entity on the fediverse is that no one pays me any mind. I'm there, but also, I am not there. I have been on the fediverse, running my own instance for nearly 6 months now and I can tell you confidently that I have thought more about what I have posted to nostr (cumulatively) than I have about what I have posted on the fediverse, and even in a few weeks of nostr the volume of writing is probably equal. I honestly credit the design of this nostr client (gossip), for breaking me out of the scroll-repost-scroll loop of non-participation participation through its deliberate lack of certain, more normified features.
I don't think of myself as a social media veteran, so to speak. I'm not 100% certain what that means. I'm just a sour, cynical online person who has a relatively healthy, and thus somewhat hostile, relationship with the technology I use.
I likely do not seem to be a nostr native as I am not one. It's neat and generally calm, bordering on pleasant, to use. I think that the chief the difference is that I (try to) use it deliberately. I think good social media is hard to use if you do not use it deliberately, and that bad social media is easy to use flippantly. Nostr natives seem to use it flippantly.
The more I consider this, the more it is why I appreciate the lack of "friendly" features on gossip. I cannot upload media, I cannot send zaps. The encouragement present within the application is for me to read, and to write, especially long-form. I've always been more accustomed to writing more on my desktop than my phone. Nostr natives, even -- and perhaps especially -- if they are new, are part of a bloc that seems to favor the mindless use of the platform. One that relies on platitudes, conforming to cultural attitudes, and being a part of the 90 in the 90-9-1 distribution.
That's probably a fairly accurate, if charitable description.
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.
Another one lost to social media addiction.
F's in the chat.
What's really good, nwah?
Shitposting, waiting for brine for chicken to cool, finished up today's grocery spreadsheet entries.
Tomorrow is grill baby grill.
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.
#[0]
> There's a lot of surface level content on here.
I think it is a sign of the normification? normifaction? that turned teh interwebz from a business/hacker/cool kid tool in the nineties to a haven for thoughtless, normie content a la today.
Dunno that the mere fact that this process is occurring implies that nostr has 20 more years of staying power, but I doubt it will be resilient to the same market forces that destroyed the web.
I suspect that nostr is likely to experience the same sort of rise to cultural prominence that 4chan did, reach critical normie (and spam) mass, drive off quality posters (or at least drive them underground on the network), and eventually settle into a slow slide from relevance as fewer and fewer people can find good content there, and slowly stop using it.
On the other hand, nostr is run by the people who use and care about it in a decentralized way, which is different than a lot of stuff that has come before it. As long as no relay, no client, no influencer becomes too large, then there is no single point of failure on nostr. Where there is a key point of influence, either over content, or over the network itself, then there is a key point of failure, and there the powers and principalities are able to focus their ire and apply more leverage than you or I would like to imagine they had. They can chip away at each place, one at a time, running down the vulnerable members of the herd until they even the odds in a head on conflict.
Will it be different enough from Reddit or 4chan to be resilient enough to survive the onslaught of censorship from within and without if it achieves the same sort of influence critical mass? Maybe normies are what kills great tools for the spread of ideas, not flaws in the medium itself.
A follow-up point is that for the reasons above, not only are relays that become too powerful bad for the overall health of the network,
individuals who become too powerful are bad for the health of the network.
Any one person who begins to be able to direct a brigade, for whatever reason, is a threat to the health of the network. Any one person who can recommend a client, or a relay, or a group, or any other current or future part of the nostr ecosystem and protocol is a threat to the health of the network. They are a homogenizing force, and not always one for the better. Nostr will be more resilient, more healthy when you use it chiefly or exclusively to talk to your friends and colleageus, not to follow important personalities online, nor those seeking to be first-past-the-post in the race to be the first influencer king of nostr.
If I could change one thing about nostr, it would be to minimize following users, and prefer instead to follow groups, to follow topics. Usenet style hierarchies of discussion would be best for nostr to defend itself against the lurking internal threat of the influencer. The follower/following relationship is how everyone else does it, and it is worth contemplating whether that model is really for the best. It has been too long since it was thoroughly examined.
/diatribe
What a dumb thing to write from such a short post, but there's a lot in it.
> "like the bearded man"
He doesn't know what a soyjak is, much less that he is one.
Only my grandmother ever did that.
Maybe you need to for real bread. I'm pretty sure what I buy (when I do) isn't.
Consent-based-morality tards should be drawn and quartered.
I hate the antichrist (web developers) so I don't mind that it does not inline media.
Gossip is pretty good. It doesn't do any webshit stuff, but it's quite functional. Read posts, write posts, check posts that replied to you, etc
Matty put in a word filter MRF that turns "nostr" into "NIGGER" the other day
God-willing we will all be dead by daylight
and aids
https://gist.github.com/fiatjaf/ea7d21e81359e1eb8abcb8805306adaa
The bounty, for reference
That is correct. As part of the bridge bounty, bridged fediverse accounts were expected to have a NIP-05 identity at the bridge, to aid in controlling the flow of posts since, as we have seen, they can be torrential for users who only want to see a few accounts but not to be drowned in the flood on things like global feeds.
One thing to consider, though is a separate toggle for whether a relay appears in the global feed. The android client nostros does this and I rather like it. A natural extension to this would be to add individuals followed from that relay back into the list. You could easily do the exact same for the domain portion of a NIP-05 identity. More (sensible) toggles is better than shotgun style "mute the living shit out of everything" a la fediverse style blocklists and dns blackholing.
I believe this would facilitate mitigating clutter on such things, and still give users flexibility, rather than being constrained by the client they use