When illustrating the Fediverse as a network, what should the nodes be?
-
@evan Cute kittens?
-
-
@evan Cats.
-
I think you have to start with instances, but I don't think you call them that. An instance is a technical term that is completely meaningless to almost everyone.
Call it a Community.
That's the core of the hierarchy.
- A Community decides to host a Social Platform
- That Community selects the types of content they want to share and then runs the appropriate software (Mastodon, PeerTube, PixelFed, Friendica, etc)
- That Community enables its members to join via the software they've set up
- That Community can then communicate with other Communities via the protocols available (ActivityPub)
The software is really secondary here. A community could run multiple pieces of software for their own purposes. In fact they probably should. The CBC Community should run both Mastodon and PeerTube.
It's not "one instance", It's a community running instances of all of the software they need.
I know you have an option for "people", but I don't think that is specific enough. It's "Communities of People".
-
@andypiper @evan @stefan I'm curious why you prefer "server" over "instance". For me, the term "server" is more ambiguous since it could be a hardware host, VPS/VM, container, software, etc. I think of an "instance" as a web origin of an ActivityPub node. Although most AP implementations host one instance on a server, it's possible to host many instances on a server (multi tenancy). Takahē and FIRM are two AP implementations that support multi-tenancy.
-
-
@evan when I got started with the fediverse this question represented all of my apprehensions about what this thing was. While I understand everything can be viewed from multiple viewpoints, I really find that the Instance as Node (or Instance as Community as Node) graph is the most intuitive for both new and veteran fedizens.
This is especially apparent when a community may operate multiple software, such as offering both Mastodon and Pixelfed, for their members.
-
I didn't answer this one. I usually do people as nodes, with some kind of boundary to indicate instances. Thanks all!
-
I didn't answer this one. I usually do people as nodes, with some kind of boundary to indicate instances. Thanks all!
@evan I'm with you on this one.
-
I didn't answer this one. I usually do people as nodes, with some kind of boundary to indicate instances. Thanks all!
I get the good intentions of the encyclopedia diagrams showing the different software packages, but I do not think it works at all.
-
@evan
What instance/server/software someone might be using is irrelevant, we all follow *people*.@alisonw correct
-
@evan I think Topics could just as well have the same rational, and it's interesting to me that it has scored so low so far.
@aeva at some point I want to use the tags.pub data to make a network diagram where nodes are hashtags and connections exist if they occur in the same content; connection strength is number of items they've been in together.
-
@manlycoffee nice
-
I didn't answer this one. I usually do people as nodes, with some kind of boundary to indicate instances. Thanks all!
@evan this is a good one!
-
-
I didn't answer this one. I usually do people as nodes, with some kind of boundary to indicate instances. Thanks all!
@evan Nodes should always be the entities signing posts IMO. If users cannot sign posts with their own keys, then you're not actually following that person and the person is not their own node. You're following a URL/ID on the actual node, which you trust to not lie to you about which person they're posting content for.
Hopefully, this will improve eventually, so that people have full sovereignty, also for moving between instances. Should be like changing your postal address, not your passport.
-
I didn't answer this one. I usually do people as nodes, with some kind of boundary to indicate instances. Thanks all!
@evan One of the nodes could be a group and another one a bot to illustrate the possible variations. Otherwise I like this illustration much better than the more common impersonal ones.
