this post was submitted on 07 Aug 2024
20 points (100.0% liked)
Open Source
823 readers
22 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I am not quite familiar with the overlap between Bitcoin and authentication. In fact it seems I assume they are totally separate things. If you care to explain further or point me to the right resources?
Perhaps I’m the one who’s mistaken.
I came to this conclusion because: From my initial cursory investigation of NOSTR, in all of the instructions to get started I found, the first step was to create a lightning wallet. Maybe I’m incorrect but, from what I understood, BTC’s authentication is one and the same with NOSTR’s authentication.
If that is the case, then it arguably be an extra step for new people to join. I fear that not many will unless already familiar with Bitcoin etc.
I’m a fan of crypto but I happen to hold the strong opinion that BTC’s authentication algorithm shouldn’t have been chosen because it’s not secure enough for future proofing. Furthermore, that BTC tie-in will alienate many people including myself. Anyway, I’d love some help forking NOSTR to NOT use BTC authentication because that task is FAR beyond my skills.
I have had a look into Nostr. My remarks perhaps will start a whole other thread but I will express them. For one thing, I had a quick look at odysh some time ago, and I have left with a sour taste about the connotations of 'censorship resistant'. Don't get me wrong I am of course against state censorship, but I (unironically-please say otherwise) wonder if there is more to this phrase than nazi dogwhistling. Within censorship resistant social networks is there a) the possibility to mass block, mitigate harassment brigades, tag nazis, and combat other types of toxic trolling and brigading? b) is there absolutely any level of moderation possible, including and going beyond the possibility to go back and delete stuff posted by trolls, or even illegal stuff like slander, hate speech, revenge porn and worse? I can't start a discussion about censorship resistant networks if these conditions are not met, because so much dogwhistling has, well, "smuggled" these meanings into the term, and I am reluctant towards it.
About the technical side of my response. I have difficulty understanding your concern, because from what I have seen so far, NOSTR is a protocol and has different implementations. As a protocol it is very liberal since it mostly goes on to specify the structure of the "event" data type. In the specification I saw that it specifies signing and verifying notes with private/public key pairs, but I haven't seen yet where on the protocol level it requires Bitcoin Lightning. Is it possible that you have looked into a specific implementation which elected to use such cryptographic keys as to make it interoperate with the Bitcoin blockchain to start with? In that case, the articles linked by the project mention that the protocol is simple and can be implemented "in a weekend". That means that instead of even forking it at all you can roll your own in your chosen framework?
Sounds great! Thanks for looking into that. I’m a bit of a jack of all trades. So, I tend to try and thoroughly vet a technology before I really dive in and commit my blood, sweat, and tears.
A couple of weeks ago, I found a previous implementation in Haskell. If I were really approaching the stack that I think will be best for the future, perhaps I should fork that one. I’m wishing Purescript was ready for prime time (was popular enough to have more educational material) because that would be a no brainer…especially the work they’ve recently been doing with a Chez Scheme back end.
I’ll start to look into it more in the coming week. Thank you so much! I have a community setup for this idea at https://infosec.pub/c/Lemventory
I may change it, though, since this is no longer Lemmy-related. As I realized, inventory is just not suited to Pub/Sub due to the need to have varying levels of security for the information being broadcast and subscribed to.