P2P/ Distributed Network Protocols

Useful clarification, thanks @bobhaugen

Counterpoint: in terms how much help the foundation gives you in developing apps to run on it,
* a protocol gives you the least
* a framework gives you quite a lot, but you still need to deploy
* a platform may not require any code at all, or might offer an API with some doc.

great indeed

I agree @bobhaugen regarding your useful distinctions, bearing in mind that you're referring specifically to web application frameworks and not the more general (and often older) uses of the extremely flexible and IMO under-used term 'framework'.

I guess the key issue to me here, as usual, is to focus on frameworks for person-to-person interactions first, and only secondarily on well-defined activities which people desire to automate through apps.

@gregorycassel

Well, some of these projects are literally protocols, and others are apps (although they may contain protocols).

That's true, but the focus of the discussion is mainly on the re-usability of the protocols used in said apps, is it not?

I personally prefer framework because I find it generic, flexible and accurate.

Funny, that's precisely why I don't think it's the right word here. I think we need to confine the discussion in each thread to more specific topics, so that as the activity in the group groups (as I hope it's about to), people can find the discussions that are most relevant to their interests and their work.

I think we’d be artificially impoverishing our language by deciding to use framework only for web application frameworks.

Oh, for sure. I guess I'm working on trademark logic here. Words can have many meanings, but it's confusing if they have multiple meanings (or overly broad usage) in a specific context. In the context of internet technology, I look at the title you suggested, and my mind automatically jumps to web frameworks, not what the discussion (so far) is actually focused on.

Of course you can call anything whatever you want to call it!

Cool. I'll change the title now. It can always be changed again as the discussion in the thread evolves.

the focus of the discussion is mainly on the re-usability of the protocols used in said apps, is it not?

Yes, good point, and I'm pretty happy with "protocol" being a key title term.

I was noticing that more about the dat protocol has been circulating recently. Has its own site at https://datproject.org/

two comments. First is an addition to, or maybe another dimension of, the "protocol vs framework vs platform" distinctions:

protocols are much more scalable and much more robust, i.e. way more p2p than the rest. Build a platform alternative to "X" (where "X" is Facebook, google, airbnb, whatever) and everybody else has nothing to do, just jump into it... because YOU carry all the tech, legal, funding etc.. burdens of scaling it up and keeping it work. To offer a platform you must become the next Zuckerberg, with the same spending and potential surveillance powers, WHOEVER "you" is (coop, government etc).

Whereas if you ONLY build a protocol, e.g. email or http, everybody can and should build and maintain their own independent but automatically interoperating part of it with their own money, policy, responsibilities, liabilities... and the whole show keeps running without an itch if you the builder, or even 30% of the "everybody" partners retire in a monastery every year.

Second comment, no, a question: may I ask WHAT do you want to do? Not HOW (i.e. protocols or platform etc), but WHAT? And by "WHAT" I mean "if Santa Claus brings you tonight unlimited money and all the programmers and other contributors you may possibly need, what will that 99.99% of human beings who can't tell a protocol from an asteroid get and who will NEVER; EVER "run their own server, exactly? What will they do with it? What will they see on their screens? What will it look like, and what will it replace? Facebook, Airbnb, whatever, all of the above?

Not having this clear is equivalent to debate how to build the next generation of electric screwdrivers, expecting that everybody will use them to build what they actually needed... e.g. a toaster, or a door handle. It would be highly worthwhile in and by itself, no doubt, but with very little practical outcome, if any. Because this is a problem space in which anything that doesn't work from the outset for that 99.99% of people above won't produce enough change, soon enough to make any meaningful difference for society.

Totally agree about protocols vs platforms.

Re what we want to build, some of us are fairly clear: we want to build software that will enable economic networks, and networks of networks, eventually constituting a new economic system. For example, https://docs.opencoopecosystem.net/

So the "protocol vs framework" hits the nail on the head, when considering Holochain as a technology. The core, agent-centric protocol would be extremely useful. Unfortunately Holochain are really driven by creating a vendor lock-in scenario: https://prezi.com/view/NvRAZ35fln9i70V3YCrl/

Looking forward, the core agent-centric protocol is not huge - the core idea being that the protocol is federated by nature, since agents must be trustless.

There are several companies we work with that have moved away from what I consider (as a founding employee - my photo is on the indigogo page) their pretty toxic internal politics and ... less than open technology.

We will have an open, federated protocol, and at least one (node.js / browser) client, that is agent-centric by September this year. It is very worth getting to grips with the concepts behind agent-centric design. Maybe you can put pressure on Holochain to actually build what they say they are! I know we couldnt do it from inside the company :)