portal-network-specs VS Joplin

Other blockchain networks struggle because it's not trivial for wallets to have embedded nodes. It's not even really easy to do on Ethereum since light clients are hard to use, but this is improving with better infrastructure. The other hurdle for the Ethereum ecosystem is the reliance on the web stack, which trains users that the default way to interact with these networks is through a web browser, which is another limiting factor for being able to run your own node. And so yeah, obviously people will rely on Infura. But it doesn't have to be like that, this is a just result of the technology being limited (irrationally self-imposed, with the reliance on web browsers) rather than users' true desires.

The solution is to build a different structure that eliminates the antagonistic relationships between the parties, where there's no economic advantage to scale. There's this project directly backed by EF doing that but that doesn't have VC backing and there's no token so obviously there's no hype machine pushing it along.

Or better, eventually, do in a distributed way with something like the portal network: https://github.com/ethereum/portal-network-specs

From the post:

> People don’t want to run their own servers, and never will...

Fair enough, but there are active efforts to develop ultra-light clients for Ethereum together with the concept of "portal network":

https://github.com/ethereum/portal-network-specs/

https://our.status.im/nimbus-fluffly/

> there’s not even a word for an actual untrusted client/server interface that will have to exist somewhere, and no acknowledgement that if successful there will ultimately be billions (!) more clients than servers.

I would not say there's "no acknowledgement" of this; depending on how deep you are in the space, it's pretty obvious that the goal is to have layered networks and mission specific networks (storage vs. messaging vs. consensus), all economically incentivized, that are p2p through and through, from the resource constrained devices of end consumers to the staking nodes that secure the networks. That's the hope, the goal, and the focus of ongoing efforts.

The opposite of the missing word is "a node in a p2p network".

The points made about the difficulty in evolving protocols quickly are not lost on me, but I guess I'm more optimistic than the author that it will happen relatively quickly in coming years, including this one. In the process, there will be opportunities seized where the protocols fall short and half-measures or worse (with respect to decentralization) will generate excitement for a time. That seems like "growing pains" to me.

Older blocks, transactions and receipts/logs would still be accessible through dedicated sub-protocols (eg. the Portal Network) or externally developed protocols (eg. TheGraph), in addition to a much smaller but still sufficient number of volunteer nodes and block explorers. Note that many dapps are already moving their historical data queries to TheGraph and similar protocols for efficiency.

Does this help? https://github.com/ethereum/stateless-ethereum-specs/wiki/Glossary

Reorganize the p2p network to make providing proofs simpler and cheaper; see Piper Merriam's work on this.

Piper Merriam's work on distributed state storage and state and witness availability: https://ethresear.ch/t/scalable-transaction-gossip/8660 and https://github.com/ethereum/stateless-ethereum-specs/pull/54

I've had great success with using Joplin for this, with Syncthing as a sync backend. Works well across OSes; I use it on Linux, macOS, Windows and Android.

https://joplinapp.org/

The tools to manipulate SQL aren't that bad, no.

But rather than having a self explanatory markdown & flat file, now I have to start learning about the schema & making specific tools (in my preferred language) for manipulating Joplin's schema.

Suddenly I'm digging through 20 different technic specs to decode what data is where, how it works, and what I can do to it. Want to edit history? This is the best help you'll get, pray it's adequately technical to expedite you to your purpose: https://github.com/laurent22/joplin/blob/dev/readme/dev/spec...

As I began with, I struggle to imagine anything that generates anywhere near as much user agency as flat files and markdown. Having boring common data & systems lets me apply portable skills I already have, rather than having to skill up in some particular product's own ecosystem.

Joplin is a good open source option too, feels more like the original Evernote in terms of UI/UX https://github.com/laurent22/joplin/

Joplin, an open source, extendable, Markdown-based hierarchical note-taking app: https://joplinapp.org/

It lets you choose a synchronization backend, offers applications for every major desktop and mobile OS (also has a terminal version). You can create notebooks and subnotebooks to organize your notes. You can also add tags for better search experience. I created notebooks for specific domains (work-related, home improvement, etc.) and also keep a "temp" for quick notes and W.I.P. snippets.

Its only con that it uses Electron on desktop which causes relatively slow start of the application.

done