Oh the irony. I clicked through to edsu.org to learn more about the backend of this note taking app, and the error I got was:
“Safari cannot open the connection because the network connection was lost.”
Show HN: A note-taking web app that won't ever betray you
71–79 of 79 posts
Re: Show HN: A note-taking web app that won't ever betray you
#72"Write some text - it'll be here when you get back....
I can promise all this because NoteToMe is an Edsu app. It means I don't have to store your data, you do ...."
The same is true of the text file I've been adding to for decades. After learning the hard way (several times) NEVER to trust someone else's prog/assume they'll be around for more than 6 months. Multiple backups sync'd religiously.
And ... no website needed! Not even a net connection! Just a 'personal computer'!
"You do have to sign up for an Edsu account...."
Whoops ... there it is.
Re: Show HN: A note-taking web app that won't ever betray you
#73Earlier quoted context omitted.
Thanks for reading! If an app wanted to be able to switch something from public to private or back, it'd get a token with write permissions for two names, one with the prv.* prefix, and one with the pub.* prefix. And that's a good thing: it makes it clear to the user that the app is requesting the ability to make the things that they write public. It's still just one grant request, it's just that there'd be two line…
And another question. It's not possible to list all the keys under some namespace, right? `prv.app.edsu-org.prefernces-app.preferences` - I can't see what are the subkeys? And I see that there is no multi-get request. So how would you implement your notes app if you have multiple notes, not one. Would you have a document which would store hashes of all notes and then fetch in parallel all of them (making n calls, 1 c…
Names are big chunky things - you want to use them as sparingly as possible, and in general they should be "well known" - meaning a list function (which does exist as pub.srv.edsu.listings.names, though it's currently not something you can request permissions to) goes pretty hard against the grain of the protocol.
Essentially, you'd only want more than one name if there's different visibility requirements for different parts of your data, or you specifically want to disconnect the state of some of data from others. All of your structure (e.g. lists, trees, lookup tables, etc.) you want to keep in the blocks.
So in your case of having multiple notes, you'd likely want the name block to keep track of the block hash of each one (so, yes, exactly as you say). And correct, if you wanted all of them you'd need to do N block-get calls. However, due to pipelining and chaining, that's not as costly as it might sound: in terms of latency it should be costless, and in terms of bandwidth the overhead is a fraction of a percent if you're using full blocks (i.e. what you'd be doing if you're concerned about bandwidth).
A lot of this stuff is quite low level (think almost SCSI kind of low level) - it's meant to be abstracted away by libraries like basic-storage.js. In that case, having multiple notes is trivial - you put each note under a different storage key, and the library sorts out how to retrieve them efficiently and update them independently, even though they're all be under the same name.
In case you haven't run into it yet, I talk a little bit more about why names are meant to be used sparingly at https://edsu.org/use-cases/storage/
Re: Show HN: A note-taking web app that won't ever betray you
#74I don't get this, is the data stored client-side or server-side?
If it's client-side, why would I need a service provider: https://edclave.com/sign-up/
Re: Show HN: A note-taking web app that won't ever betray you
#75I don't get this, is the data stored client-side or server-side? If it's client-side, why would I need a service provider: https://edclave.com/sign-up/
It's stored on the server.
Re: Show HN: A note-taking web app that won't ever betray you
#76Have you heard of Scuttlebutt? https://www.scuttlebutt.nz/
How does EDSU compare?
Re: Show HN: A note-taking web app that won't ever betray you
#77I actually found that using special directory for notes and git and grep is actually convenient. The only thing I'm missing is fuzzy search features of grep, like build on word2vec models.
Can we call this the Dropbox syndrome where people boasts they have a better solution with combination of cli tools instead of a service?
If you are privacy focused it is a better solution.
Re: Show HN: A note-taking web app that won't ever betray you
#78Have you heard of Scuttlebutt? https://www.scuttlebutt.nz/ How does EDSU compare?
Similar in that you get to keep your own data.
Different in that it's lower level - it's not a social networking protocol - it's something you can build a social networking protocol on.
Re: Show HN: A note-taking web app that won't ever betray you
#79Earlier quoted context omitted.
That's what I'm suggesting, but I'm pointing out the fact that CRDTs are generally append only data structures and it's possible to run into space issues with them eventually for some users.
A lot of CRDTs are append-only. But not all! Quite a few that are state-based, auto-compacting, space-saving, small & efficient! More info in a discussion on this: https://twitter.com/marknadal/status/1008610024875122688
A CRDT which models edits of arbitrary text with essentially unbounded revision history (required for merging) almost certainly can only grow (monotonically?) in size. Maybe you can be smart about compression, but I don't think it can ever shrink. Someone smarter than me can probably formally prove this with an argument about entropy while considering a series of particularly pathological edits.
But you're right that I'm wrong when I say "[all] CRDTs are generally append only structures." I meant to say "text-revision CRDTs are generally append only data structures."