Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A note-taking web app that won't ever betray you

noteto.me

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Show HN: A note-taking web app that won't ever betray you

#41

Post by podviaznikov »

Hi, edsu seems very interesting. I've looked through examples and read docs. Question: is it possible to make an app and allow user to set permissions. E.g. lets say I have writing app. I want initially to create writings as `private` and then promote them to `public`.

I don't see if it's possible. I see that scope is fixed for now in the name like that `prv.app.edsu-org.hello-world.storage`. So I assume `token` only works for `prv.app.edsu-org.hello-world.storage` but wouldn't work for `pub.app.edsu-org.hello-world.storage` or would it?

Re: Show HN: A note-taking web app that won't ever betray you

#42

Post by heathjohns »

marknadal wrote: post #33
heathjohns wrote: post #31

Earlier quoted context omitted.

I absolutely sympathize with the concern - but I don't believe it's an a priori solvable problem. Bitcoin is theoretically fully decentralized, but when I sold mine off it took 2 days to sync the chain - I get why people use Coinbase. I'd still be running my own email server right now if it weren't for spam. My point is that I think there's inflection points - when weaknesses in design or implementation become appare…

I admire that. Don't let any counter argument ever stop you. Parallel experiments are critical for success. With that said, can't we say that the federated experiment has already played out? Particularly, in email? What new innovation or changes do you think will make the story play out differently this time around, versus outright P2P/decentralization? Thanks!

(Oh man, sorry, this ended up being an essay!)

Take, for instance, statically-hosted HTTP: if I'm, say, hosting at AWS and I want to switch to Netlify, it's trivial - I just change the place I upload my files to and switch the DNS. To me that's a complete success in decentralization - there's no hassle, no compatibility problems, no one other than me even knows that I've made the change.

So I don't see it as federated being a lost cause, I see it as a protocol needing to be an HTTP not an email.

For Edsu, it's something that I've considered at every design choice. For instance, the data storage format fully specified and trivial, and hopefully therefore trivially transferable. And there's features like transparent proxying/forwarding of usernames. But I'll absolutely admit I've not been able to completely mitigate it, aside from urging people to BYOD (Bring Your Own Domain).

However, a lot of it comes down factors that aren't the protocol itself. I'm hoping that Edsu's userbase is mostly just the open source community, with its consolidation-hostile "herding cats" nature. When Facebook first showed up, it struck me as a home page for people who didn't want to deal with HTML. So in a way, it was a bifurcation of HTML users, with the technical and non-technical people each going their own way. And in the technical people's world, HTML stayed a commodity.

SSH is another successful federated protocol - but only in the technical community. My family members don't use SSH, and that's just fine with me. That's one big advantage relative to alternatives that focus on social networking - Edsu is useful even if only a minority of people use it. And even email had 22 years before Gmail happened - if we've got 2 decades before we need to come up with a better thing than Edsu because the eternal September boat finally docked, I think that's fine.

So for sure, the gestalt at the moment is that full decentralization is the way to go. Edsu is a hedge - a bet against that. Federated is the devil we know, and there's successful examples of it avoiding its biggest problem. On the other hand, I think full decentralization's challenges are still unknown, and so A) it's unclear if it's any more resistant to centralization (a la Coinbase), and B) it might have other emergent bugbears that are an even bigger problem.

I think only time will tell.

Re: Show HN: A note-taking web app that won't ever betray you

#43

Post by heathjohns »

podviaznikov wrote: post #41

Hi, edsu seems very interesting. I've looked through examples and read docs. Question: is it possible to make an app and allow user to set permissions. E.g. lets say I have writing app. I want initially to create writings as `private` and then promote them to `public`. I don't see if it's possible. I see that scope is fixed for now in the name like that `prv.app.edsu-org.hello-world.storage`. So I assume `token` only…

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 items instead of one. Also, names are simple pointers to blocks of data, so, for instance, if both names happen to be pointing to the same written piece, there's no duplication of data.

Re: Show HN: A note-taking web app that won't ever betray you

#44

Post by podviaznikov »

heathjohns wrote: post #43
podviaznikov wrote: post #41

Hi, edsu seems very interesting. I've looked through examples and read docs. Question: is it possible to make an app and allow user to set permissions. E.g. lets say I have writing app. I want initially to create writings as `private` and then promote them to `public`. I don't see if it's possible. I see that scope is fixed for now in the name like that `prv.app.edsu-org.hello-world.storage`. So I assume `token` only…

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…

Perfect! Makes sense

Re: Show HN: A note-taking web app that won't ever betray you

#45

Post by heathjohns »

gtt wrote: post #16

I 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.

Funnily enough, Edsu and git's data stores are very similar in that they're both Merkle trees. It means that they both have similar benefits of trivial checkpointing, automatically deduplicating revision histories, etc.

So if you squint enough, Edsu is kind of an "APIized" version of your setup :) So in addition to text files, it can also be structured application data.

Re: Show HN: A note-taking web app that won't ever betray you

#46

Post by gpm »

nikkwong wrote: post #37
larkeith wrote: post #32

Earlier quoted context omitted.

...I just described a subsection of git... although with better UX.

But let’s say for example your phone and your computer are clients, and your computer has latest version of your data. When you open your phone, if your computer is not on the internet, you won’t be able to get latest. So, would this be practically useful for a terribly trivial use case like this?

Have a server be just another peer, not privileged in any way, but always online and available.

Maybe do the routing through a distributed hash table like we use for finding torrent peers (perhaps even the exact "mainline" DHT torrents use), which would mean that even with the server being down you could still sync with your other online clients.

Re: Show HN: A note-taking web app that won't ever betray you

#47

Post by heathjohns »

z3t4 wrote: post #17

I think edsu could be nice for "serverless" apps, eg static web apps. Should make it work offline. And edsu should keep a copy of the data on the client. Then sync once the client is online.

Edsu's data store is content-addressed - i.e. everything is hashed and immutable from a storage perspective.

A great thing about this is it makes a lot of caching problems simply go away. So while there's no explicit support for local caches disconnecting and then re-connecting later, the underlying protocol gives any library wanting to implement this feature a lot of support for it.

Re: Show HN: A note-taking web app that won't ever betray you

#48

Post by podviaznikov »

heathjohns wrote: post #43
podviaznikov wrote: post #41

Hi, edsu seems very interesting. I've looked through examples and read docs. Question: is it possible to make an app and allow user to set permissions. E.g. lets say I have writing app. I want initially to create writings as `private` and then promote them to `public`. I don't see if it's possible. I see that scope is fixed for now in the name like that `prv.app.edsu-org.hello-world.storage`. So I assume `token` only…

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 call per note)?

Re: Show HN: A note-taking web app that won't ever betray you

#49

Post by EGreg »

larkeith wrote: post #27
heathjohns wrote: post #12

Earlier quoted context omitted.

You're right about the sync part, but it's an old skool client-server sync, not a peer-to-peer one.

Hmmm, a p2p version that uses local storage on each device you have could have some interesting applications. As a client-server architecture it's a tad complex for a lot of users to set up, but with a good UI it could become a viable alternative storage method, as well as allowing for potential app cross-compatibility. You would have to make sure at devices had a chance to sync - perhaps have a web service there? -…

Look at the WebTorrent project!

Re: Show HN: A note-taking web app that won't ever betray you

#50

Post by EGreg »

tylerhou wrote: post #39
larkeith wrote: post #27

Earlier quoted context omitted.

Hmmm, a p2p version that uses local storage on each device you have could have some interesting applications. As a client-server architecture it's a tad complex for a lot of users to set up, but with a good UI it could become a viable alternative storage method, as well as allowing for potential app cross-compatibility. You would have to make sure at devices had a chance to sync - perhaps have a web service there? -…

It's possible and there has been research in this area, see http://archagon.net/blog/2018/03/24/data-laced-with-history/ for details about conflict resolution. The main problem is garbage collection - to guarantee that you can sync across all devices for all time, your data structure must be append-only, so your document can only grow. A long living document will eventually grow very very large. You could let the use…

Just use a CRDT
Post reply on HN