I recently made a post about Shinigami Eyes and BlockParty and started thinking about activist tools.
The ones mentioned are of course merely mitigation tools, but speaking of activist tools more broadly, like some people suggest Signal and Tor Browser for activists, as a fine balance between security and a low technical bar for entrance.
I am not really sure that any of these differ substantially from Matrix and Firefox and why they are so special.
The ActivityPub protocol. the one Lemmy uses, is a mature protocol and people have put thought in various aspects of it.
Apart from Lemmy, there are ActivityPub applications that foster activist and IRL communication, like Framasoft’s Mobilizon.
The main issue I would think of about ActivityPub instances for community organizing is the lack of specialized features for this type of work, like polling.
And the major issue of course is the pseudonymity/anonymity and completely open signups renders existing apps like Lemmy untenable for community activism organizing.
In your opinion, what would it take for an Activity Pub application to be a secure, efficient tool for community activism?
If you find that the fediverse isnt the right tech for this kind of thing, have a look at NOSTR. I recently learned about it in the context of my hypothetical Lemmy fork. For what I am trying to do with it (decentralized retail inventory), NOSTR was much better suited than Lemmy. My only issue with it is that it ties bitcoin lightning walllets into its authentication mechanism (a dealbreaker for me at least). My future uses for it would be FAR different than yours but it also seems more well-suited to activism as well.
Sure, the use case is remote to say the least, but the decentralized thing is appealing. I will have to wrap my head around the bitcoin registration thing, since I am not familiar with crypto. But I did imagine something like decentralized exchange or shops as part of community organizing. In that manner you can, for instance, support web creators within a given community etc. So, perhaps the use case not that far as it initially seems.
If you want to have a go at using that NOSTR tech but stripping the lightning wallet thing out for another (less BTC maximalist but equally or even more secure) form of authentication, I’d be very interested. I’m obviously not going to roll my own auth from scratch….but as I see it, tying BTC to it could prevent MANY people from giving an otherwise very promising tech a chance. Besides, there are already far more secure cryptographic elliptical curves in use by other cryptocurrencies that NOSTR conspicuously passed over in favor of BTC’s.
I probably don’t have the resources nor experience to do it myself but I’d love for this tech to exist.
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.
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?