this post was submitted on 07 Aug 2024
21 points (86.2% liked)
Open Source
31031 readers
825 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
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.
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.