neonmodem VS orbitdb

They seem to have spent a ton of time on their website, why link to the github with no information? https://neonmodem.com/

Shameless plug: Neon Modem Overdrive [1] supports HN, for anyone looking for a Go single-binary multi-platform TUI.

[1] https://neonmodem.com

Thank you for the detailed description of your idea. Indeed, if you're willing to accept the shortcomings of a dedicated USENET infrastructure, then it is definitely something that could be done. In fact, I did consider NNTP for another project of mine (https://github.com/mrusme/neonmodem), which might eventually swallow up Superhighway84 altogether. If you're interested in actually giving it a try and implement a functional NNTP library for Go I'd be more than happy to make use of it! :-)

> Superhighway84 it was very expensive for me to actually run the software

I agree with you, in terms of efficiency IPFS is still miles away from where it should be. Hence my feedback on Quiet, as I do not perceive IPFS to radically imrpove within the next few months or even years. And as you correctly stated it looks like Quiet uses some workarounds to improve on the overall mediocre efficiency of IPFS, which however lead to shortcomings on other ends:

> Quiet itself notes a limit of 30-100 individuals with its application

However, this is not how P2P should be. I'd be truly curious to hear from someone at OpenSea, or Fleek, or any of the services that offer high volume IPFS hosting about their experience and gut feeling on its future. I personally gave up on hosting my website via IPFS myself -- which I did for a brief period of time -- mainly for these exact reasons.

> but for those of us who are bandwidth-constrained or otherwise limited in our access to those technologies

I believe that quite on the contrary, this might benefit these people the most. Imagine not having to do the roundtrip from your phone, to a server on the internet, back to your computer, just to have a synchronized state of your address book available.

Similarly, imagine writing with someone in your city -- let's say Melbourne, Australia -- without your messages first travelling to Utah, USA, and then back again. My gut feeling is that overall congestion on the internet could even be reduced, by allowing more applications to communicate directly within small meshes rather than travel all the way across the globe and back again. That is, as soon as there are more efficient ways to deal with the overhead that is currently breaking IPFS' neck.

A BBS-style command line client that supports various projects as backends and seamlessly integrates them into a streamlined user interface. (Website, Github).

Besides, have you seen this Lemmy client? Neon Modem Overdrive

Yes, including Neon Modem Overdrive, for a retro BBS experience.

Someone created a Usenet-like thing on IPFS. https://github.com/mrusme/superhighway84

It's kind of dead. IIRC the dev put that on the back burner in favor of a new BBS-like app. https://github.com/mrusme/neonmodem

OrbitDB is not well-funded, but there's fresh work happening recently by some dedicated volunteers: https://github.com/orbitdb/orbitdb/commits/main

I've been thinking it might be practical to build a simple decentralized database, where agents just know each other, so conflict resolution does not need to be so strong and can rely on the social layer.

I think this applies to most databases, but I'm particularly thinking of internal enterprise databases, some social networks, any federated database system, and different devices of a single user

I'm thinking of this features:

1- Append-only?, full history of operations. Deletes / edits do not remove data, they only modify the "active state"

2- Agents are public keys or similar (DIDs?)

3- Operations are signed, and receivers verify if operation is valid, and sender is allowed

4- Operations form a Merkel-DAG (similar to git, they link to the tips of current "active state", like a commit/merge in git)

So far I think I've basically described [OrbitDB](https://github.com/orbitdb/orbit-db)

Consensus is where things get real hard, [OrbitDb seems to use a last-write-wins CRDT](https://news.ycombinator.com/item?id=22920204), and although I don't know the details of orbitDb, I think for many simple use-cases, conflicts can just be resolved on the social layer. But I think we need to provide agents with good tools to resolve conflicts

I'll try my best here with some ideas:

- When merging, we can order operations by their timestamp, if operations enter conflict, raise it to the conflicting agents, or someone with permission to solve them.

If an agent makes public an operation that forks its own history, mark agent as malicious or compromised, alert other agents, this needs resolution on the social layer, you have proof of misconduct, an agent has signed diverging operations

Any operation becomes fully settled if you have proof that all agents of your system have referenced it directly or indirectly through newer operations.

Timestamps can be upgraded by using @opentimestamps to get proof that an operation existed at time X (prevents creation of operations in hindsight). Though this does not prove operation has been made public

Both use OrbitDB: Peer-to-Peer Databases for the Decentralized Web. JavaScript. MIT license. repo

I think a wallet-agnostic memo solution is definitely the way. Having wallets that end up (partly) incompatible is only gonna hurt the UX. Maybe a decentralised DB solution like OrbitDB or GunDB can be the best way forward, although I haven't dove deeply into the docs yet.

Checkout this https://github.com/orbitdb/orbit-db peer-to-peer database for the decentralized Web.