PLAN @ Dweb 2019

[drew-512]

Howdy from Austin TX! PLAN Systems is super excited for DWeb Camp 2019!

PLAN Systems is a non-profit charity, developing and providing publicly available systems that foster robust digital self-reliance. PLAN is a spatial communication and logistics tool that supports persistent collaboration for communities and organizations to operate and self-organize.

At this year's DWeb event, we will be demoing what has been years of visioning and has gone into production in Fall 2018. PLAN is an ambitious project, but it offers a feature set that is highly compelling:

• Community-Centric Permissions Model: permissions emanate outward from a community's authority structure, NOT from an external and/or global authority.
• Total Data Ownership: a community's data is their own, encrypted as such, and is cryptographically only available to a community's members. PLAN Systems is to PLAN as Red Hat is to Red Hat Linux (except that we're a non-profit).
• Total Data Privacy: a community replicated data store is surrounded by a cryptographic city wall. Only members of a given PLAN community gain possession of their community's keyring, which is required to decrypt the community's replicated datastore.
• 3D-based Client: PLAN's "thin" client is authored in Unity, a highly capable multi-platform 3D engine historically used for games. In PLAN, Unity is used as the client layer, allowing the entire machine to be leveraged. Above all, PLAN is intended for non-technical users.
• Offline First: PLAN's data model is designed so that a community can be partitioned for prolonged periods and community member can still work. For example, Alice and Bob each take their computers off-grid and can continue to work and interact even though they don't have connectivity beyond a local subnet.
• Leverages Blockchain: PLAN's lowest layer, the Persistent Data Interface (PDI) layer, is modeled as an append-only datastore. This allows a PLAN community to use either a central server or a compatible (private) blockchain to persistently store a community's data, depending on their performance, security, or decentralization needs.
• Leverages IPFS: When a community needs to store bulk data (e.g. video, audio), PLAN's Cloud File Interface (CFI) abstracts content-based storage. Hashnames to this content are stored via PLAN's persistent channels (stored at the PDI layer). This allows a given community node to drop (unpin) previous revisions once a new revision is posted for a given logical file.
• Real-World Security Provisioning: PLAN's data model has security features so that the consequences of a user private key loss or compromise are mitigated, and social key recovery can occur. Further, since the primary data model derives from an append-only datastore, a community can always opt roll back the primary data record (PDI) to any point in the past. Given PLAN's Community-Centric Permissions Model, such choices remain in the hands of the community and not in the hands of a distant authority not in relationship with the community.
• End-to-End Security: pluggable, industry-standard crypto. Public key exchange performed in the community's reserved Member Registry Channel and channels can be made private. Inspired from IRC, in a private channel, the channel owner distributes the channel's private keys, encoding them using each member's latest public key.
• Pluggable, Open Standards, FOSS, GPL3: PLAN Systems' mission ultimately is to benefit humanity and serve the public. PLAN Systems is a 501(c)(3) pending org.

To oversimplify, you can imagine the PLAN user experience this way: start with Slack but channels can be placed into spatial containers (which are also channels). Multiple references to channels can be placed anywhere -- on 2D maps, in abstract spaces, on timeline spaces, or in any other channel. Finally, each channel conforms to its own protocol (like MIME-type), where each channel entry conforms to to standards asserted by the channel's immutable protocol descriptor. For each protocol, a channel "adapter" exists on the client side and on the PLAN node ("pnode") side to process the protocol messages. So PLAN developers can make custom channel adapters on the client for existing protocols, or they can make proprietary custom protocols entirely.

Our vision for DWeb Camping 2019 is to arrive with our PLAN pre-alpha prototype to demo all this in action for the given local geography. We'll add channels in real-time on the area map, annotate the campgrounds, and invite members to that community -- and watch as changes propagate to other community member nodes. We're in the process of getting the prototype up and running, but the functionality and proof of concept will be there for everyone to experience and take in!

As far as using the event's network, as long as it conforms to basic subnet behavior and discovery, then we'll just plug in a couple headless nodes (running on Intel) NUCs and we'll have a few laptops floating around for others to play with. We'll demo adding community members so that others can use their own machine to access the DWeb community we'll have going.

To learn more, check out the PLAN Systems homepage.

To skip right to the technicals, we suggest starting with the PLAN Design & Engineering Docs.

See y'all there!

Drew O'Meara
PLAN Systems Technical Director

[benhylau]

Thanks for submitting this project @drew-512. This project is now listed on https://dwebcamp.org/proposals/

[pospi]

This sounds like a really interesting project. Curious if the creators are aware of REA accounting and http://valueflo.ws/ - there are some implementations underway on Scuttlebutt and Holochain which may have some crossover with your efforts. Look forward to discussing opportunities for collaboration and interoperability! (:

[drew-512]

Awesome, looks great! So excited to help y'all rock the event and have fun doing it! :) Drew

…

On Mon, May 20, 2019 at 1:28 AM Benedict Lau ***@***.***> wrote: Thanks for submitting this project @drew-512 <https://github.com/drew-512>. This project is now listed on https://dwebcamp.org/proposals/ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16?email_source=notifications&email_token=AIRREZA4BL5VYCWL326XLVLPWJAKHA5CNFSM4HJF7WFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVX2AWQ#issuecomment-493854810>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIRREZGR7RWPOX2BTKX2ZCTPWJAKHANCNFSM4HJF7WFA> .

[drew-512]

This sounds like a really interesting project. Curious if the creators are aware of REA accounting and http://valueflo.ws/ - there are some implementations underway on Scuttlebutt and Holochain which may have some crossover with your efforts. Look forward to discussing opportunities for collaboration and interoperability! (:

Hi!

Thanks! We're getting great feedback so far but we understand seeing the prototype is believing! Understandably, people comment that the project is ambitious, but PLAN offers something fundamentally different than what's out there by bringing in so many foundational areas into a unified, open data model intended to solve real-world problems for humans, logistics, privacy, and total data ownership.

[benhylau]

@pospi I am interested in learning about how valueflow integrates into existing ecosystems. For example:

there are some implementations underway on Scuttlebutt and Holochain

I am imagining valueflow implementations will allow these networks of people to interact differently? What are the interfaces and expected outcomes?

[pospi]

Depending on what you mean by 'interfaces', reading into the Open App Ecosystem or Open Cooperative Ecosystem might start to answer your questions. ValueFlows was originally spawned out of discussions in the OAE Loomio group as to how to create highly modular, pluggable architectures for a suite of open, interoperable apps.

The other answer to your question might be that it's a vocab, so it's just an API spec to plug into your backend. Since we're converging on GraphQL that makes it pretty easy to wire up (see Holochain or Scuttlebutt adapters implemented as schema resolvers).

As to expected outcomes... that's a pretty broad topic. More ethical production practises is basically my top of the list. From a technical perspective it's about having choice at every layer of the stack- you could even have individual components built on different platforms in the architecture we have planned out. Conscious not to hijack this thread though and I have been meaning to put something out there for an REA co-design session...