As the Internet is alive with the sounds of #twittermigration these past days, I returned to some earlier thoughts and ideas, w.r.t to both self-hosting fediverse instances, and mapping those on to the business network of my company.
The resulting question is, would a set-up like this work?
If our company would set-up their own fediverse instance (m.tgl.eu here, with accounts for our team). This gives all of our team a ‘verified’, because of the company url, presence as part of their current work. That doesn’t mean we can’t have other accounts (see @ton in the image). And others in our network would do the same (names of organisations for illustration purposes).
If we would run one instance together (samenhankelijk.nl here), that is a relay for all the instances of the organisations involved, and the instance for any individuals in our network (@w… here).
Then we would have a fediverse network of our company’s actual network, where it becomes easier to interact more frequently across the entire network, where discovery is possible because of the shared public timelines through the relay. It’s bounded by being a representation of an actual network, but open within that and based on the permissive boundaries the various organisations themselves have.
I’m not sure if this is how ActivityPub relays are meant to work or are useful, but that’s what I want to explore.
A few of those building blocks are easy to set-up, a company instance and the instance to function as relay. Others are harder, getting our own instance used (we have internal asynchronous interaction through our own rocket.chat instance), getting others in our network to take the same steps.
Notions that play a role in this
My company is part of a network of similar groups and initiatives. Internally we call them friends of our company. These are the people and organisations we invite to events and parties, that we like to hang out with, jam about ideas with, and when possible work together with. That can be because we worked together in the past and thought that was fun and worth repeating, or because we share or shared office space, have similar perspectives or visions, and having overlapping or complementing activities. It’s a network of individuals in larger organisations that we interact with individually, and companies, non-profits and NGO’s that are Zebra’s, like us.
I think that technology should be smaller than us, in order to provide agency to us. With smaller I mean that the deployment and daily use of a tool must fall within the control and capabilities of the user or user group. Specifically the off-switch should be in control of the user group itself. That way a user group can use a tool under their control to address issues that group has by themselves in their own context. This is what I call networked agency. Different groups can strengthen their tools and work, by networking with other groups, yet tools stay useful on their own and get more useful when connected.
I also think that human networks of connections are similar to the structure of peer-to-peer internet structures. A network of many smaller nodes and areas where those connections are denser, individual nodes that are more intensively connected to others and form a local center. I’m convinced our digital tools work better if they deliberately mimic that human network structure, so that the digital affordances those tools provide flow naturally into the human network connections we all have. That’s what I call human digital networks, and distributed digital transformation.
Openness is a necessity in the networked age. But it also needs a limit. That limit is tied to our personal limits, the way we need to feel ‘at home’ in the context in which we exchange ideas. With the new influx of many new people on Mastodon I noticed how my timeline is feeling more alienating than before when it was more like hanging out in my favourite watering hole in town. That will settle, I’m sure, yet in social platforms that treat the entire globe as the same public square you are continuously exposed to the algorithmically amplified onslaught of all of it all the time. Which does not reflect human network reality anymore. Bounded openness matches that reality better.
All this maps on to the fediverse I think: if each company or group in our network has their own instance, that allows internal interaction and public interaction in parallel, and if that public interaction is always visible locally in all other instance in the network, then more direct and deeper ties between the people in the network may grow. Such interaction would create more ideas, more initiatives and help spot more opportunities to do things together I think (or equally quickly expose we’re not as nicely aligned or matched as we thought).
@ton Intreresting idea to use this as an extranet… Or network of Intranets
@Marleen @Palinuro @publicspaces omdat ik jullie noem in deze posting…. en omdat ik graag hoor hoe jullie daar over denken: ‘How to federate like our business ecosystem? https://www.zylstra.org/blog/2022/11/how-to-federate-like-our-business-ecosystem/
How To Federate Like Our Business Ecosystem? – Interdependent Thoughts
@ton @Marleen @Palinuro @publicspaces interessant, daar komen we even op terug. Maar een relay is meestal een ander stukje software dan Mastodon. Dit bijvoorbeeld is een open source ActivityPub relay: https://github.com/yukimochi/Activity-Relay/wiki/02.-Control
02. Control · yukimochi/Activity-Relay Wiki
@toon @Marleen @Palinuro @publicspaces ah, ok, TIL. Dus relays kun je geheel onafhankelijk van instances opzetten?
@ton interessante gedachte: “digital tools work better if they deliberately mimic [a] human network structure” .
@ton That makes sense and actually sounds like a brilliant experiment. I might actually try it for my company as well.
@euan @IanYorston our company instance as of a few days is at https://m.tgl.eu
The Green Land on Mastodon
running my own hosted since ’18 (m.tzyl.nl) as household instance, as it reduces moderation and dependency to nearly 0. Also now running 1 for my company (m.tgl.eu) for the team bc zylstra.org/blog/2022/11/h… & zylstra.org/blog/2022/11/o…