[gpm]

This assumes that edsu will never betray you.

Given the broad meaning of betray used, that seems unlikely. If edsu gets big it will have to pay for all that storage somehow. Like all things edsu will one day come to an end, and like most websites/companies/endeavors it will probably come to an end before I do.

[ex3xu]

While I'm just hearing about this Edsu project and am not in any position to vouch for it re: future betrayal, I think the specific concern you raised is solved by Edsu by using local storage rather than a centralized repository.

A few clicks in, the first line of https://edclave.com/ is:

"Edsu makes life better for both developers and users of Online Open Source Software (OOSS). Instead of the developer having to hold on to your data, you do. It gives you more control, and gives them less to worry about."

[Waterluvian]

Local storage feels really quite volatile. It lives on a local disk inside your browser. May as well just use notepad and a file.

[beatgammit]

It seems the data stays in sync with other places you're signed in, so supposedly you could get redundancy by signing in on more devices/browsers. In that sense, it's better than a crappy text editor on your computer.

[heathjohns]

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

[larkeith]

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? - and I'm unsure how you would deal with conflict resolution, but the idea definitely seems to have a lot of potential.

I'll need to think about this.

[tylerhou]

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 user decide when to collect garbage/establish a new baseline doc; maybe like 5 years. But this means that if you edited the document on a laptop, didn't sync it with another client, and then closed the laptop for 5 years you would lose the ability for the changes you made on that laptop to be resolved automatically.

[larkeith]

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

[EGreg]

Look at the WebTorrent project!

[heathjohns]

You can run an Edsu server locally, but I wouldn't. It's meant to be run on an internet-accessible server - a $2.50/month VPS would do, or if you don't want to run your own there's at least one provider that will do it for you.

[stephengillie]

Notepad++ and Dropbox work quite well together.

[heathjohns]

Good point, and you're right: the buck has to stop somewhere.

However, Edsu is a federated protocol with an open source implementation. So it only disappears when the last person to care about it stops keeping it up to date with the compiler. That's about as good a guarantee as you can get, I think (e.g. telnet is still around after 49 years).

[marknadal]

Edsu seems to rely on federated services.

Email, similarly, unfortunately fell to convenience - GMail, with Google selling your data.

The parent brings up a good point, how do we know Edsu won't betray its users? Or that it won't become dominated by a centralized provider?

I'd love to hear an answer.

For me, our team decided to take a route that cannot be compromised - your identity belongs to you, fully decentralized (https://gun.eco/docs/Todo-Dapp), yet can do 0-server password resets and other conveniences.

[larkeith]

I know I'm a bit of a broken record, but a <noscript> notice that JS is required is always appreciated rather than a blank page.

[marknadal]

Apologies, yeah, the site has an interactive coding tutorial that teaches you to write and run your JS. <noscript> would be good - make a PR? https://github.com/gundb/gun-site/blob/master/docs/src/index...

[heathjohns]

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 apparent - where centralization can get a foothold, and I don't think it's inevitable which course things take at those points. HTTP hosting, for example, has some big players, but it's still very much a commodity.

I realize that this is a crowded field, with lots of contenders, like yours. I think it's an important enough problem that it warrants parallel attempts, so that at least one of them sticks. Edsu picks a very specific strategy, which is that it's a compromise - it's not like, say, IPFS in its level of decentralization. For an app platform, I think there's challenges enough at any level of decentralization, and Edsu tries to b-line it straight there by being very orthodox and old-skool in nearly every other way. I thought it was a good bet, but only time will tell.

Props for the password resets, BTW. The importance of that feature is underappreciated :)

[marknadal]

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!

[heathjohns]

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

[marknadal]

Hey, great stuff here.

Well stated, kindly argued.

I really look forward to what you build now, 6months, 2 years+ from now. :)

[heathjohns]

Very nice of you to say. Thanks for your interest, and best of luck :)

[StavrosK]

From a five-second glance at their website, the main selling point is that you can self-host it.