Skip to main content

ucomm — universal communicator middleware for Ethereum Swarm

tests license status

Working title. Naming is an open question (see ROADMAP.md, issue N-1).

Every communication app — chat, email, calls, streams, forums, social feeds — moves information of some kind from one or more people to one or more people. The apps differ in a handful of parameters (topology, interactivity, persistence, privacy, invitation granularity), not in principle. Yet on Swarm, as elsewhere, each project rebuilds the same primitives from scratch and ships its own silo, its own inbox, and its own notification settings.

ucomm is middleware that factors out the common core:

  • a channel kernel: a channel is a set of per-author append-only logs, a merge rule, and a parameter vector fixed at genesis; every event is one signed envelope.
  • an attention layer: a first-class control plane for requesting human attention, based on Attila Lendvai's priority taxonomy (importance × urgency, ceilings, offsets, thresholds), made incentive-compatible with postage costs, attention bonds, and local reputation.
  • a universal inbox: one local notification daemon per device arbitrates all attention requests across all channels and apps; apps become views and policy defaults, not silos.
  • a discovery/recommendation layer: WoT-weighted collaborative filtering plus concept-based (OntoDAG) content filtering, feeding priors into the attention engine.

Guiding principle: receiver sovereignty. Everything a sender or channel declares (priority, offsets, importance) is advisory and signed; the receiver's local policy engine is the only authority over the receiver's attention.

Repository layout

docs/DESIGN.md          Architecture: two planes, channel kernel, profiles, transports
docs/ATTENTION.md       Attention economy: priority algebra, policy engine, mechanisms
docs/RECOMMENDATION.md  Discovery & collaborative filtering (needs merge from prior notes)
docs/ROADMAP.md         Module decomposition, milestones, initial issues
docs/USER_GUIDE.md      Tutorial: motivation, project overview, install, worked examples
CLAUDE.md               Instructions and invariants for Claude Code sessions
src/ucomm/              Python package (schema, policy engine, signing, chat profile)
tests/                  pytest suite

Status

M0 (schema + algebra) and M1 (known-contact channels over Swarm) are done — see docs/ROADMAP.md for the full milestone/issue breakdown. Concretely: the envelope/genesis schema with canonical encoding and validation; the priority algebra and policy engine with golden decision tests; per-author logs with deterministic causal-DAG merge, backed by either an in-memory implementation or a real recordstore/Bee adapter; real secp256k1 envelope signing (via swarm-bee) and out-of-band contact exchange; and a two-party/ group chat profile exercising all of the above end-to-end, confirmed against a live Bee node. New here? Start with docs/USER_GUIDE.md.

M2 (notification daemon + universal inbox) is in progress: a private channel directory, a graded active/obsolete dashboard (a projection, recomputed on demand — never persisted), read-state aggregation across every channel, a push/hint-delivery interface, and the IMAP bridge's conversion layer (email → the same envelopes and dashboard, no live mailbox yet) are done. Left: an actual hint backend, IMAP's live fetch loop, and the Nostr bridge — see docs/USER_GUIDE.md sections 11–13 for the directory/dashboard/hints/bridge demos. GSOC-based rendezvous (unsolicited contact, group discovery) stays behind the Rendezvous interface, pending the GSOC/pub-sub work by Viktor Tóth and Viktor Trón. Broadcast-style 1:N live streaming is explicitly out of scope here — Solar Punk Ltd's own swarm-hls-stream/Swarmcast line already owns that (DESIGN.md §5).

On decentralization, read this before evaluating further: everything above runs on Swarm feeds and needs no full node — a light client is enough. Real-time push notification and unsolicited-contact discovery (PSS and GSOC) are a different story: both require a full node, yours or a relay's, and that relay sees traffic metadata, which is a real centralization point still unresolved (not just a caveat) — see docs/DESIGN.md §5 and §11. Nothing here should be evaluated as "fully decentralized" without that qualification.

  • recordstore (github.com/petfold/recordstore) — candidate persistence substrate for author logs (versioned key → record over Swarm; POT track).
  • swarmfs (github.com/petfold/swarmfs) — fsspec backend, useful for payload blobs.
  • OntoDAG / mdl-fca — semantic concept DAG; content-based half of the recommendation layer.
  • Attila Lendvai, Computer aided human communication (codeberg.org/attila.lendvai/publications) — source of the attention taxonomy.

Metadata

Release files for ucomm 0.0.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for ucomm 0.0.1
File Size Uploaded Provenance Actions
ucomm-0.0.1.tar.gz 40.8 kB Without provenance Details for ucomm-0.0.1.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for ucomm 0.0.1
File Interpreter ABI Platform Actions
ucomm-0.0.1-py3-none-any.whl Python 3 none any Details for ucomm-0.0.1-py3-none-any.whl

Total release size: 73.2 kB

Release files / ucomm-0.0.1.tar.gz

Download URL ucomm-0.0.1.tar.gz
Size 40.8 kB
Tags Source
SHA-256 checksum
How to use checksums
9a1f10641244c65b5c31d7dce2f581a2865914bf4483aaf0e7e6c789d6f1e6d2
BLAKE2b-256 checksum
How to use checksums
ab00988ad09d21dbea15aa5025b417338b7c617df13564e71089fe7112c65466
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.3

Release files / ucomm-0.0.1-py3-none-any.whl

Download URL ucomm-0.0.1-py3-none-any.whl
Size 32.4 kB
Tags Python 3
SHA-256 checksum
How to use checksums
7159ac49a45dd93f9769b7768169a3993262a4196bdceb89ed18486847ad56c7
BLAKE2b-256 checksum
How to use checksums
9d39ee382ac86b9e6cea729cc9cdee104bf0e9005b494657e09789a88b39c317
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.3

Security for ucomm 0.0.1

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Release history Release notifications | RSS feed

This release

0.0.1 This release

2 release files No provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page