Agenda, next meetup

Items for discussion, before anything is decided or written into a definition.

World-Augments

Raised 2026-09-27. A World-Augment is something from elsewhere that would add to your world: an object, its code (possibly WebAssembly) and its Appearance.

Proposed

• It carries everything a commercial message must (Publication, Publication.Messages): a Publisher behind it, attribution and accountability, one answerable source, blockable as an entity, a point for feedback and a way to measure how it does.
• It arrives as a gift: wrapped, and inert. It is carried like any message, and passes unseen unless you have a receiver in your world, as with the HereYouGoCommercial receiver. Wrapped, it does nothing.
• What it would reach is told from what it declares, before it is unwrapped: inside your world, or out of it. An object whose code keeps only its own state can do no more than that state says.
• Something returns: its fate, killed or appreciated, to its one source, as a commercial message's does; and a gift in return.
• The receiver is itself a commercial thing, and arrives the same way: gift-wrapped, with a Publisher of its own. A receiver's wrap is always seen, its wrapping and its Publisher, never what is inside; seeing a wrap is not being advertised to, and unwrapping it is consent. That is how the first receiver reaches you without one. Unwrapped and set down, it shows commercial messages from any Publisher; its own Publisher is only who made it.
• Anyone may publish one: independents too. No app ships or pins a Publisher's key. A Publisher is its domain -- the attribution Publication already asks for -- and publishes its own public key there, over HTTPS, at a well-known address. A World-Augment is a package that names its Publisher's domain and is signed with that key: HTTPS vouches for the key, and the signature carries that to the package, however it travels after. Blocking a Publisher is blocking its domain.
• The package and its Publisher's key are fetched together, as one action: the download. Checking the signature, keeping it wrapped, and unwrapping it later tell the Publisher nothing more. A key once fetched is kept, by domain.

Proposed: the package, the same in every implementation

A package says everything in shared, versioned terms, and needs nothing only one implementation has.

• Behaviour is declared, not built in: what an object does is said in records from a shared list in InterOp -- grows, lights, sounds, displaces, and so on -- which each implementation reads in its own way. Code beyond that list comes as WebAssembly, on the same terms as any object's code: what its maker gives in, as text, and its own state out, as text; nothing else.
• What is not known is not acted on: a record an implementation does not know is ignored, and reaches nothing. Records carry a version in their names, as Material's derivations do (photokinetics/derive-colour@1); records of a Publisher's own live under its domain.
• Formats are named in InterOp: one for shapes, one for sounds; the looks are words, answered by each device (Material). Every file in a package is named by its SHA-256 digest.
• The signature is over the manifest's bytes exactly as they are, and the manifest names every other file by its digest: nothing has to be encoded again, the same way, before a signature can be checked.
• A kind is named by its Publisher's domain -- example.org/forest-spruce -- so two Publishers' kinds never meet by name, and "one per world" counts by the whole name.
• InterOp keeps packages to test against, each with what must become of it: a valid one, a signature tampered with, a file whose digest does not match, a kind not known, a record not known, a second of what may be only one per world.

To settle

• What the wrapping is on the wire -- the package, proposed above -- and what a declaration of reach looks like.
• Which shape format and which sound every implementation reads: USD or glTF; AAC or Opus.
• Whether the receiver is the HereYouGoCommercial receiver itself, or one of its own.
• Whether other wraps are seen without a receiver too, or only a receiver's.
• What a gift in return is, who chooses it, and whether it is owed or free.
• Whether a fate travels back along the Gossip road, or on a path to the source.
• How this sits with WebAssembly: sandboxing, and what the host hands in.
• The well-known address, and what is published there: a key of its own, or the key an ActivityPub actor already has.
• How a Publisher changes its key, and what becomes of packages signed with the old one.
• What a package is when its Publisher cannot be reached at the download: refused, or kept wrapped and unconfirmed until it can.

🔙 to the Inter-Operability Forum