💾 Archived View for jb55.com › ward.asia.wiki.org › ephemeral-content captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
We suggest a new kind of content that can be created and shared within the federation with new rules for authorship and persistence. We intend this for fast distribution as one would expect in a conversation but with a well supported path to curated persistence expected of a wiki.
We imagine ephemeral content mediated by a plugin with client-side and server-side components. We might call this a Channel and expect their instances to proliferate within the pages of the federation.
Content added to a Channel by typing, speaking or dragging will find temporary residence within the server-side component where it can be replicated and distributed to all viewers of the item in units similar to those managed by Paragraph, Image, Audio and Video plugins.
A Channel behaves like a Factory with a delayed impact on the page. As one writes into a Channel prototype items are created and shared but not yet if ever added to the page and recorded in the Journal.
The logged in owner of a page can see content appear within a Channel and choose the prototype items from there to be added to their page as if they had entered them themselves in a Factory.
The mechanics of selective keeping would be similar to what we see today when we split text in the Text Editor. Imagine Channel contents displayed in some way, possibly gray, so that its impermanence is obvious. When clicked to keep an ephemeral item would be added to the page above the Channel and only subsequent ephemeral items would remain.
An author that chooses to selectively keep content from a Channel is thus curating their permanent record of the conversation. Other authors might choose differently and their choices are open to side-by-side viewing and copying as is our tradition.
In the mechanism we suggest the author that chooses to keep an item is implicitly discarding the unkept items above it. It is possible that the Channel view would maintain that place in the Channel by observing the presents of kept items on the page. In this way recovering an earlier revision of the page might expose not-yet lost content still available in the channel.
The server-side Channel plugin has visibility of all ephemeral content hosted by a server. It would want to know when items are kept and others discarded so that it can apply storage management heuristics of its own.
This centralized storage creates the communication path between authors that gives the Channel properties implicit in its name. We'll call content made available to an author independent of their own writing "remote" content.
The server-side Channel has access to the fork history of the page and from this can discover sites outside of its own. We will call these "remote" channels because they are remote to the server, not just remote to the author.
We expect remote channels to discover each other from hints in the fork history and from this establish a non-hierarchical real-time distribution network. Forking a Channel on to a new server is thus establishing a subscription to this network.
We expect ephemeral items flowing through the Channel network to be as varied as those created by any Factory. The server-side may cautiously ignore content of types for which it is not provisioned.
We expect an upper limit on the size of items shared through the Channel network. Any item that is to be kept would face the same post message site limit of a few megabytes. Short voice recordings, such as explanations of related content, will hopefully be allowed up to a minute or two.
A page with many kept voice clips would eventually out grow the size easily kept in page json. We might then need some way to promote these to Assets or some similar but more share optimized store.
We might concoct new client-side affordances for generating conversationally useful items.
We might devise some sort of push-to-talk button that starts a voice recording and recognizes immediately when it should stop.
We might devise some sort of screen-region-recorder that makes acceptably small videos for sharing through the network.
There could be a natural delivery latency which make ephemeral content suitable for chat room behavior but would fall short of live conferencing.
We might use the network for optimizing and distributing bandwidth-aware live peer-to-peer. connections suitable for medium to large conferences.
There could be a natural retention period for ephemeral content that makes it suitable as an open comments section even as we have resisted this temptation.
HTML5 clone of Apple's AirDrop - easy P2P file transfer powered by WebRTC. github
How do you create a video chat application? Six steps. Four approaches to scaling. post