P2P/ Distributed Network Protocols

• Solid: https://github.com/solid/
• SSB: https://www.scuttlebutt.nz/
• DAT goes together with Beaker: https://medium.com/blue-link-labs/building-a-decentralized-peer-to-peer-photos-app-with-beaker-and-dat-c8a470202b4c
• IPFS: https://ipfs.io/

I am also looking closely at Holochain. I spoke to Samer from https://p2pmodels.eu/ about it, they will consider it as well. SENSORICA and p2pModels will probably collaborate. I like Holo because it is agent-centric, and because they like asset-based and service-based currencies. This is what we are also looking for with SENSORICA, currencies that are backed by economic activity and utility currency. Moreover, the whole notion of current-see is something that we want to implement in SENSORICA. Not to mention our alignment on values, culture, worldview... They start with a p2p cloud application and we want to explore how we can move our CMS and CRM out of Google. I did my part in Montreal and that resulted in 5 holoports being purchased. So we put our money where our belief is.

Ditto @tiberiusbrastavice beta CM will be on Rails - well underway, but we're thinking gamma in Holo. Rails will make it easier to grow the market but distributed hosting through Holo makes so much sense. Understanding is we'll need to build our own blockchain for CM currency, but when activity is managed through Holo apps, can look at exchanging for Holo.

CM currency is based around P2P marketing

Would it be useful to rename this thread to reflect that it quickly became a broader discussion (and an important one)? We could all learn a lot from comparing and contrasting the various projects defining standards and building blocks for federated and decentralized networks of apps and sites, such as those listed earlier in this thread by @bobhaugen

I'd second that - perhaps "existing distributed framework projects" or similar?

That could work. I'd say we're technically looking at distributed activity frameworks, or p2p activity frameworks. (But 'distributed framework' is more concise, and probably better if it seems reasonably clear.)

Language can get so tricky here! Distributed/ P2P, definitely. "Activity" is gaining a narrower technical definition, but I would go with "network". Are we talking about "frameworks" though? That makes me think of web frameworks like Rails in the Ruby world, or Zope/ Django in the Python world. I would go with a title like "P2P/ Distributed Network Protocols". Any objections?

Well, some of these projects are literally protocols, and others are apps (although they may contain protocols). I personally prefer framework because I find it generic, flexible and accurate. Web frameworks can't own the term 'framework' any more than, say, a car chassis could own it. I think we'd be artificially impoverishing our language by deciding to use framework only for web application frameworks.

The term I personally use in one of my key docs is 'organizing framework'. Not sure why I didn't think of that up here above.

Of course you can call anything whatever you want to call it! I just try, in my social circles, to generally steward the potential of English to be used as flexibly and accurately as feasible.

The differences in my mind between protocol, framework, and platform include:
* a protocol usually has a specification, and if you can follow the specification, you can use the protocol. So the Web stack was a protocol. Many independently-developed Web servers and clients and pages use the protocol.
* a protocol usually has some software that runs it, but if it is really a protocol, many independent software components can run and interact with each other using the protocol.
* a framework is usually a set of software components that people can use to develop applications.
* so for example, with Holochain, we are creating a framework that will run top of Holochain the protocol, that we and others can use to develop economic network apps.
* we and others are developing similar frameworks for the ActivityPub and SSB protocols.
* I see some differences of opinion on platforms, but to me, and platform is an all-embracing, usually centralized, system, that will usually be developed on a framework, using a protocol, but you are usually stuck using the platform's implementations of the framework and the protocol.

So in terms of degrees of freedom for independent development:
* a protocol has the most
* a framework has less
* a platform has the least (of those three).