sbazerque

It's not purely a technical matter, there are different market dynamics at play as well.

If you go cloud, you get a handful of very large suppliers, that provide a lot of non-standardized services that are probably going to lock you in like hell (as the article wel says).

If you build infra, you're using /mostly/ commoditized supplies and skills.

If the cloud offerings where interchangeable and the industry reasonably fragmented, the margins of cloud providers would be slimmer and the paradox would probably go away (in favor of: always cloud!).

See for example Porter's analysis framework [1] and how your positioning changes in the two cases.

https://en.wikipedia.org/wiki/Porter%27s_five_forces_analysi...

It's not really designed to model collaboratively edited text (yet?) but as the backend for multi user apps (social, workspace, commerce, etc)

No relation, IIRC HyperCore was called DAT when I chose the Hyper Hyper Space name

\o/

That's cool!

> I've been kicking around the idea of writing a CRDT-based editor using this model.

I got around to creating a data layer (p2p, browser-based, CRDT-backed) for something like this:

https://github.com/hyperhyperspace/hyperhyperspace-core

I'd be interested in collaborating on your editor

I think not, what he describes is really the way some of these tools work.

This seems... convoluted.

What does he mean by pre-rendering? Do they spin-up a browser-like environment on the server and use that to render the page and cache it? Or has that idea been improved upon?

It is somewhat whacky, but what I'm doing is:

I created a library to have distributed data types directly on the browser [1]. So there are no servers, data is sync'd directly between people's browsers.

Then I created a library to bind react components directly to my distributed data types [2]. So the app is just a static page, hosted anywhere, that works as an SPA.

[1] https://github.com/hyperhyperspace/hyperhyperspace-core

[2] https://github.com/hyperhyperspace/hyperhyperspace-react

Depends on whether you've gone crypto or not. If each patch is authored and signed by some form of crypto id in a permissionless p2p system, there's no central authority to create the compact version of the patch.

Hey Mike!

Mike is working on it as well:

https://braid.news/

In my view the lack of authentication in the original semantic web concept made it a SEO gaming vector for years and years.

Knowing who to trust is as hard a problem as basic understanding / semantics.

We use IndexedDB, and in modern browsers the limit should be at least a few hundred megabytes (see for example this answer for Chrome limits [1], the situation is similar in Firefox).

So far this has been enough, but the apps we have are fairly simple (e.g. no media!). We'll see. Maybe media can be handled off browser.

[1] https://web.dev/storage-for-the-web/#how-much

I'm working on it, Ben [1].

Believe me, it is no easy thing to do.

[1] https://github.com/hyperhyperspace/hyperhyperspace-core

I wonder how much of the tracking would still be necessary if Facebook didn't limit the organic reach of local business pages, as I understand they do in order to boost their ad offerings, and allowed them some space in the feed based purely on the likes/fans/comments they have as they did in the early years.

An interesting complement to your view is questioning the role of work in our ethics and sense of purpose, as elaborated for example in Russell's "In praise of idleness".

I was amazed by how well a fully p2p solution fits right into the real-time data problem the author is describing.

Is Google still a coveted place to work in the US? Sounds kind of implausible, I was reminded of the excellent "are we the baddies?" video posted here a few weeks ago :)

Look at Hyper Hyper Space!

https://github.com/hyperhyperspace

Its goals are similar, the approach is more pragmatic (p2p data layer using standard web browsers and webrtc).

Yeah, many more in https://CRDT.tech

Incidentally, Microsoft is probably the only big tech co that could perhaps profit from dweb-style tech.

> Each message can be linked by its content addressable hash.

What I had in mind is, while as you well said, you can link the data in a pub in any way you need, the distribution model is fixed. The only way to change that is creating more pubs.

I think the distribution model is an integral part of the data structure in a general p2p setting and needs to be customizable, within reason.

Cheers!

Yeah, except Hypercore or SSB sync'ed data types are not as flexible as the relational model.

I'm building something like this, with one extra requirement: permissionless / trustless p2p operation. It works in the browser, here's the README:

https://github.com/hyperhyperspace/hyperhyperspace-core

Good question. I was thinking in terms of market share alone.

If phone OSs were a reasonably fragmented market, you as a phone buyer could probably choose a phone that doesn't restrict what software you can run and still meet your other requirements (e.g. tight OS & hardware integration). Also, as a software maker no single phone OS company would have much leverage over you.

But some of these things could also be argued on principle.

That's fine, Miguel. But it should be a choice. Apple's market share is large enough to have them forcibly unbundle their app store and OS businesses (like Microsoft and IE in the precambric era).

Yeah, this is mine https://GitHub.com/hyperhyperspace

Raising cattle, programming the dwebs, carpentry, sailing

That's intersting! In the case of persistent threads as mentioned in the link, can the set of moderators be mutable, and still have eventual consistency?

Yes, it was for a chat proof-of-concept app. But the end result ended up being so convoluted I thought no sane person would program like that, so I went back to the drawing board.

Look at _init() here to get a feel of it:

https://github.com/hyperhyperspace/hyperhyperspace-web/blob/...

An interesting problem is how much interface mismatch you get when you try to solve real-life problems using CRDTs.

Awhile back I implemented the "become a connection" logic for a project that has purely CRDTs datatypes, and I kind of went back and forth between composing well known CRDTs to model all the possible state, or just implementing the solution as a finite state machine whose CRDT-ability had to be reasoned for this particular purpose. Ending doing the second.

Got the intuition that this is a very nice way to think about distributed software but the right abstractions may not be in place just yet.

This sounds a lot like my own side project's goals, but I've made it work inside the browser using web-rtc. There's a (somewhat) usable prototype online.

https://www.hyperhyperspace.org