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.

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.

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.

Edited. Good call.

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.

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.

I got you, fam(ily). It has a real smooth, simple ring to it. ;)

Temu: contribute to the irreversible heat death of your own planet just to save some money on useless, piss poor quality trinkets created out of cancer-causing, hazardous materials using slave labor coupled with unfair market practices that are then shipped thousands of miles over the oceans using the world’s worst polluting container ships… like a billionaire.

That should be their slogan.

edit: added slave labor, unfair market practices edit: added hazmat

Judging by the state of the US, you’re much more likely to be right than I am, you cynical bastard!

😂

🤣

Trains are awesome and I fully support them but let’s not be idealistic here and pretend that true self driving cars will never happen.

Edit: jokes on you! I made a grammatical correction that makes your reply IRRELEVANT. 😉

SELF-DRIVING TECHNOLOGY SHOULD BE STANDARDIZED AND OPEN SOURCE.

Any other implementation puts profits over human lives.

NixOS

Over the last decade, free software developers have been repeatedly tempted by development tools that offer the ability to build free software more efficiently or powerfully.

The only cost, we are told, is that the tools themselves are nonfree or run as network services with code we cannot see, copy, or run ourselves. In their decisions to use these tools and services—services such as BitKeeper, SourceForge, Google Code and GitHub—free software developers have made “ends-justify-the-means” decisions that trade away the freedom of both their developer communities and their users. These decisions to embrace nonfree and private development tools undermine our credibility in advocating for software freedom and compromise our freedom, and that of our users, in ways that we should reject.

In 2002, Linus Torvalds announced that the kernel Linux would move to the “BitKeeper” distributed version control system (DVCS). While the decision generated much alarm and debate, BitKeeper allowed kernel developers to work in a distributed fashion in a way that, at the time, was unsupported by free software tools—some Linux developers decided that benefits were worth the trade-off in developers’ freedom. Three years later the skeptics were vindicated when BitKeeper’s owner, Larry McVoy, revoked several core kernel developers’ gratis licenses to BitKeeper after Andrew Tridgell attempted to write a free replacement for BitKeeper. Kernel developers were forced to write their own free software replacement: the project now known as Git.

Of course, free software’s relationships to nonfree development tools is much larger than BitKeeper. The source to the free software development support service SourceForge was once available to its users but its authors have returned to a completely closed model. While SourceForge is built using free software, SourceForge users interact with the software over the web. Because users never have any copy of the SourceForge software, they can never demand source. Similar projects like CollabNet’s Tigris.org, Google Code’s “Open Source Project Hosting” services, and GitHub, each served similar purposes and have kept their code similarly out of reach. Their services are often provided without charge and promoted for free software development, but this commitment does not extend to their own software that runs the development platforms. The source code to each of these systems remains private and unmodifiable by the developers using the services.

These nonfree development tools present a dilemma for many free software developers. The goal of many of these tools is, through more efficient free software development, more free software and more freedom. CollabNet, Google and GitHub each claim to want free software to succeed and claim they want to help it. For a series of reasons though these companies choose to support software freedom through means that are less in line with free software ethics than the ones they seek to create. The result is developers who are disempowered. The software freedom of the code these hackers produce is contingent on unacceptable exclusivity.

First, the use of nonfree tools sends an unacceptable message to users of the free software produced. “Software freedom is important for you as users,” developers seem to say, “but not for us.” Such behavior undermines the basic effectiveness of the strong ethical commitment at the heart of the free software movement. As those that are already committed to free software, we should demonstrate that we can succeed—and thrive—using free software. We should support free alternatives to proprietary systems such as Savane which can replace SourceForge or Google Code and runs GNU Savannah, or Gitorious which can replace GitHub—by using them and by improving them in the areas where they fall short.

Secondly, we should realize that, going forward, the software we produce is only as free as the software it depends on for its continued use, distribution, and evolution.

The GNU GPL license and source code mean little to a user attempting to modify a program without free access to the software required to make that modification. It is not only developers’ freedom at stake but, eventually, their users and all future “downstream” developers as well. Those choosing to use nonfree tools put everyone at the whim of the groups and individuals who produce the tools they depend on.

While proprietary development tools may help free software developers create more free software in the short term, it is at an unacceptable cost. In the controversial area of private software and network services, free software developers should err on the side of “too much” freedom. To compromise our principles in attempts to achieve more freedom is self-defeating, unstable, and ultimately unfair, to our users and to the larger free software development community.

Just as the early GNU maintainers first focused on creating free tools for creating free software, we should ensure that we can produce software freely and using unambiguously free tools. Our failure to do so will result in software that is, indirectly, less free. We should resist using tools that do not allow us the freedoms we are trying to provide our users in the development of their software and we should apply pressure on the producers of our development tools. Free software has not achieved success by compromising our principles. We will not be well served, technically, pragmatically, or ethically, by compromising on freedom of the tools we use to build a free world.