Features are derived from the design.

High level approach

  • Build on existing solutions
  • Everyone is a dev (scale contributors)
    • pluggable system
    • fork-and-modify workflow
  • Text first - text performs, text is accessible

Basic functionality

The usual suspects for any networked service:


  • general posture is toward protection from centralized attackers
  • information is only shared and received directly from trusted parties
  • not accessible from public internet
  • multiple points of control and change quorum
  • automated SecOps
    • protection rings
    • incontrovertible “ring 0” level to reassert control
    • automatic key rotation


  • high availability (clustering)
  • data is never lost
    • multiple encrypted copies of all data
  • familiar “share” paradigm


  • average cost must be very low
  • mostly hosted and controlled using consumer internet connections and devices
  • multi-tenant shared hosting for higher throughput and availability

Feature ideas (work in progress)

  • Only connect directly to people you know in real life
    • transitive trust model: individuals will declare transitive trust for particular topics they think their connections are trustworthy about. e.g. if Bruce was a direct contact, I might transtively trust everything he shared tagged “security”. in practice, this might work like automatically forwarding any post Bruce posted about and tagged “security”. in this way, content can propagate to a large group of people only if it’s considered share-worthy by significant numbers of individuals.
    • individuals are out of direct contact by any particular untrusted entity
  • Ubiquitous sharing
    • users are purposefully categorizing every bit of media they consume in order to contribute to their social groups
    • every person has a rich set of content that’s been filtered by their direct contacts
  • Decision making
    • if someone wants help making a decision, they can send a quorum request to any set of contacts
    • terms of quorum are fully customizable by the requestor
    • they define the topic, goal for quorum, and coordinate time for the group to interact according to the terms. this includes when (and if) to meet, reply, disagree, agree, discuss, etc.
  • Ad-hoc virtual micronetwork swarms
    • time-based deterministic rendevous to stay hidden from scanning
    • every complete network requires at least three parties - two users as well as a hosting node. users can lose connection and rejoin because the hosting node persists interaction state. even if one party loses connection, there are multiple nodes present for redundancy.
  • Self-hosted via P2P omni-architecture swarms
    • any hardware anywhere can be a host, subject to bandwidth and performance capacity
    • high availability
    • data durability
    • disaster recovery
    • multi-tenancy among small trusted groups
  • In-person key and OTP exchange
    • establish strong trust roots in person to eliminate third party (CA) trust
    • long-lived, durable, expensive identities
    • inviolable OTP streams for both parties
    • key heirarchy for trust rekey and security recovery
  • Multi-factor data control
    • require two devices to publish, create, or destroy resources
    • negotiated rekeying to continually erode security compromise footholds
  • Flexible trust model
    • deputize others with security capabilities (this is how infra is shared)
    • granular trust ratings (rate 0-100 for no trust to full trust)
    • granular trust categories (crosses with ratings) (example: trust Ben as a host for rendevous, include Ron’s transitive network for quorum forming, alert about every message from Ben about Linux)
  • Automatic credential rotation for continually renewed forward secrecy
  • ML or manual topic filtering
  • Quorum-seeking groups - “how we decide what to do”
    • temporary groups for the purpose of discussing some topic
    • transitively established connections for “social rumoring”
    • “better than average” participant trustworthiness?
    • plugins/services - die roll, connect to tcp port for pub/sub text relay chat, start video/audio streaming to IP, collaborative diagrams for problem modeling, multi-choice poll
    • quorum templates for guided discussion