We suggest a new workflow for collaborative research which consists of a gathering phase followed by reflection and then synthesis.
The simplest mathematical models of animal swarms generally represent individual animals as following three rules. wikipedia - Move in the same direction as their neighbours - Remain close to their neighbours - Avoid collisions with their neighbours
# Gathering
We need the ability to easily create a wiki page from a copied url on mobile. The groups we are working with are constantly sharing links in chat groups to videos or external sites. But when on mobile so far that has been impossible to move this conversation to wiki. How could we design a wiki page that works on mobile and allows copy and paste creation of a wiki page?
Captured content could go into a read-only commons as page json, suitably acknowledged. When members of the group become more reflective they can fork these pages as the start of their compositions. This would have the advantage of not polluting the federation with bookmarks.
This seemed like a good application for our outpost pattern. So we've created a proof of concept. glitch
The main motivation for this experiment is to test the direction we're heading with this combination of static wiki and outposts. But also to confirm that rewriting with modern HTML and javascript will make it easier to work on mobile devices.
# Synthesis
The mobile friendly application will support collective browsing in an area of declared interest while constructing pages from which creative synthesis can emerge.
Each posted link will be briefly and meaningfully titled. This will name the resource.
Each posted link will include a keyword laden synopsis that relates this resource to interests of the swarm
Each posted link will create a page in a shared, read-only site that appears to be "forked" from the posting author.
The swarms will operate a bit like Bohm dialogs in that they have an organizing question to which participants will speak by posting relevant content.
A swarm will close after a week of inactivity but will persist as a Pod with a Roster where the contributors will be immortalized as founders.
# Application
We now sketch the moving parts of a link swarming application. As is our tradition we seek a decentralized approach. As such we anticipate multiple client implementations using a well established API agains an open and easily hosted server.
Clients will vary depending on the mobile platforms supported, the degree of integration with other services on the platform, and the skills and interests of the mobile developers.
A single ES6 module will launch within deno a server configured to manage a flat-file database consisting of JSON content organized and managed as Assets folders and serve read-only wiki content to the federation.
cd .wiki/swarms.fed.wiki deno run http://c2.com/modules/hive.js
The client-facing API will provide a REST interface to swarm descriptions, memberships, and recent activity. For a given user, the interface will provide a list of engaged swarms, and all posts to each swarm if asked.
A POST will validate that the user's site is a wiki and that the welcome page "about us" item contains a link to an extant and non-empty page. Beyond the ability to follow these conventions, no further login will be required. The server will not write to a user's site.
.
This page has been assembled from direct contributions by David Bovill, Eric Dobbs and Ward Cunningham. Many others contributed indirectly.