Infrastructuring thro federating - Building a commons of platform toolspace
A commons.hour special
Date: Thursday, May 25, 2023
Time: 17:00 London time. (European time = +1, N America Eastern time = -5, N America Pacific time - -8).
Venue: commons.hour room (@ DE server)
This is a session to explore potential dimensions of federated provisioning in platform space. meet.coop has always been a federation of coops, as well as supporting the principle of federation in the sphere of libre software and distributed infrastructure. It looks like the next phase in meet. coop’s evolution may involve federation in a slightly different way. So this is a good time to convene some broader discussion among friends who share this generic commitment and have current experience or intentions for federating.
Possible dimensions for federated relationships, to be discussed, include:
A Provisioning servers (bare metal) - server rental
B Provisioning servers (virtual machines) - server rental
C Provisioning sysadmin media & tools (scripts, package mounting tools, etc) - admin toolkits
D Provisioning ready-to-mount software packages (containers etc) - repos
E Pooling sysadmin labour (work hours)
F Provisioning a full ‘back-end’ (A, B, C, E above) - Full hosting service for tools
G Mix-&-match provision of tools to coop members, across differing toolstacks hosted by different hosts - platform-to-platform federation (for example, BBB in one toolstack, Jitsi in another, maybe Talk in another (NextCloud) toolstack)
All of this is back-end (platform) federating: provisioning of a platform tools commons. Also there might be front-end federating: supporting fluent mobilising of tools in a given (diverse, federated) infrastructural back-end (F above) in different communities of users, (geographic regions, language communities, sectors of interest, etc). Whichever we are attempting, stewarding a federated platform infrastructure and its mobilisation, across a mix of provider- and user-communities, is necessarily a core issue. In the future, meet.coop will need to pay more careful attention to this, so governance intentions and practices are a key part of the puzzle.
Although historicaly meet.coop is involved in front-end federating too, the core of the present discussion is federating of back-end provisioning. @petter and @flancian have some views and will contribute. Others with related experience are mentioned in a post below.
@jamie /@Jaime @ May First Movement Technology (mayFirst regards security and privacy as militating against hosting distributed across separate organisations?)
Thank you for the invite, I’m sorry I was unable to attend. I do want to add some clarifying comments.
I don’t believe we’ve ever expressed that sentiment and if something came across that way it is a misunderstanding. I can think of lots of scenarios where hosting different bits of information across separate organizations could be a benefit to security and privacy.
I do think however there are obstacles to linking different services, federated or decentralized between separate organizations if there are different expectations for privacy and security within each organization/platform as well a different expectations about who is allowed to be included and access this information. I think trying to coordinate policy across separate organizations with different governance models would likely be a significant challenge, not impossible. Doing all of this within a single organization and cultivating clear agreements among its members is definitely easier and so that is where we start.
May First really is just a small cooperative working hard to make our existing services work better for our members within our existing mission, expectations and agreements. That doesn’t mean we reject more federated or decentralized approaches to internet services, we just haven’t had time to work on these things technically or consult with our members about how it should work politically.
Thanks @jamie for saying clearly what you previously wrote: my misinterpretation. The complexity of the social relations might easily be too much to handle with available ‘cultural’ and small-p political bandwidth, for a small organisation (even worse with a larger one? You provide a good caveat:
we just haven’t had time to work on these things technically or consult with our members about how it should work politically
Here’s a map of eleven kinds of contributions that can be made in a commons of digital infrastructure like meet. coop. Any of these could in principle be federated - not just the sysadmin back end, but also the membership front-end, or outreach.
The shared notes, public chat and slide deck are in this folder
More highlighting to follow in the next couple of days, in this thread Evolution #2 - Infrastructuring through federating. Hoping to pull a specific focus, on practical, modest, simple next steps that might be possible in this kind of strategy of federating, in the coming months, as meet. coop moves into a federal relationship w WebTV and re-fashions the Board of Stewards @gcotnoir@evolutionEvolution 1 - Find a new home
The notes from this session Nextcloud include a number of points where action might be taken in the short term, as meet. coop migrates to an operational alliance with WebTV. Discussion and updates continue in this thread: Evolution #2 - Infrastructuring through federating
You provide a good caveat:
