Talk:Memebrand

use scenarios

basic uses

Publish permanently

1. Finish writing a document D.
2. Toggle Global context (this could happen first)
3. Publish D

   note: this sets D up in a queue to be added to any receiving local server

4. check connection to local server

   option: explicitly upload D to a server

   option: explicitly ask for broad spectrum mirroring and propagation

5. Power off laptop, never use it again

result: D should be available from local server and any other repository that trusts the author and wishes to mirror published works; for the foreseeable future. (see whitelist/blacklist scenario)

Publish locally

1. Write a doc E with two friends.

   From its inception, it is in a context shared by the three of you, if not a Neighborhood context

2. Toggle Neighborhood context
3. Publish E, as one of the authors
4. check connection to local server

   push E to the server

5. verify that a complete copy of E has been transferred there)
6. Power off all three laptops, none of you ever use them again

result: E remains available from the local server to anyone on the local net, but is not passed on to other servers or repositories, and is not published to people visiting the local server's IP from other regions.

Publish dynamic collaboration to a group

1. Write a doc F with twelve others, in the sharing context of the group.
2. The doc splits and remerges a great deal among the collaborators; it is not one steady stream of versions. Publish a few times in the middle of this stream of changes.
3. I publish this doc to a fixed name three different times, and it becomes three versions of that doc with that name, last published by me; with whatever attribution metadata it has gathered.
   1. Different collaborators' journals will contain different sets of versions of the collab, there may be confusion and variances in what each person caches.
4. Mary and I publish a shared version of the doc simultaneously; the published versions are different (different published-by metadata, at least), with their own permalinks.

result: the explicitly published versions are strongly preserved and stored.

Subcase : overwriting/deleting : see below

Whitelist and blacklist authors

1. Compile local list of contributors with known good reputations
2. Compile local list of sporadic contributors known as spammers or vandals
3. Sign and publish lists globally; each repository can choose which lists to aggregate and republish as their guides for prioritizing what to mirror

result: limited range for publishing network abuse

tricky collabs, not yet supported

Ongoing publishing

1. Turn global publishing ON; set default license parameters.
2. Contribute to a dozen available projects. My contributions are now published as above, though the collab as a whole in each case may have a different envelope published/licensed status.
3. Review contributions : to potentially add new unilateral licenses (for instance, I forgot that I was contributing LGPL material to a BSD project, and a CC-SA image to a PD text).

other tricky use cases

Publish, then change metadata : Once something is published, new metadata should result in a new version; perhaps a minor version indicated in a specific way.

Publish, then delete or overwrite :

• this should be done in a soft way (suggesting deletion for mirrors and archives that care), with a hard option to prevent deletion/overwriting, and [perhaps] another to force deletion/overwriting. The former would be an explicit note to preserve this version. The latter would be an explicit "delete on request" flag sent out with the original work.
• Which is to say, if one publishes something without a force-delete/update-on-request a flag, not even a change of heart -- or a vandal spoofing one's identity -- would force those works to be deleted... though archives might for space or other reasons compress what they reshare and only include the latest revision of a given doc.

current implementation

As of ship.2, there is no way to publish materials locally within an XO network, short of a web service provided by a machine on the local network that can be contacted via the browser. A webserver and WSGI framework is being added to the builds to enable future development of such services.