The federation unites creators who agree to share work in progress. Privileged access to resources dictate that some work exist outside of this community. We consider here what responsibilities an outpost has to the federation and vice versa.
We have considered the mechanics necessary to offer pages that can be read and forked. See Federating Foreign Servers. We add to this consistent interpretation of information flowing into and out of the site.
We gracefully transitioned from ruby to node by strict adherence to conventions based on a then available test suite. Now we consider actively exploring new kinds of interactions based on ES6 modules, TypeScript and the deno secure runtime. To what standards should we adhere?
# Outbound
Local plugins should have federation friendly type, id and text fields where the text prints with a 'Help' button when the type is unfamiliar.
Local pages should have a Journal that begins with a 'create' that duplicates the generated content.
Local pages should include descriptive paragraphs that describe what the page contains and how it might be understood. This must be easily authored in the outpost's computational environment.
Where live data is interactively viewed and manipulated a non-interactive capture of the result should be available on the same or easily located page. See github 
# Inbound
Local environment should understand standard item types: paragraph, image, reference, roster and assets.
Local environment should resolve a Collaborative Link based on page resident site information.
Local environment should maintain a neighborhood of encountered sites and identify twins when they occur.
.
Mike Bostock explains why one might want a server and how to add one to Observables using amazon. post