feat: To Federate or Not To Federate?

[Speykious]

Area

server

Problem

We have to decide how instances and authentication are handled for the backend. We have several options to consider.

First, whether the auth server and instance server should be separated or not. For example, Minecraft has a centralized auth server, but we can run and host our own Minecraft servers; with GitLab however, the authentication is managed by the instance, so you need one account per instance.

In light of that, given that the Loki server is undoubtedly going to be a FOSS project, it makes sense to just endorse people making their own instances. Although it makes things simpler, having only one centralized instance isn't ideal in that regard.

The question now is, do we federate or not? Do we allow different instances to talk to each other?
What are the pros and cons of each decision, and what sub-options do we have ? How does it affect UX in specific cases? What other implications are there?

The different models we discuss will tell us whether we want to have the auth server separated from the instance server.

Suggested solution

My favorite solution so far, since I intuitively know how it might work, is the Minecraft model. We have a central auth server and the possibility of creating our own instances. "Instance" in this case means "guild", or maybe even group of guilds.

Pros

People can host their own instance of the Loki server, and it would be really easy to join a server that's on a custom instance. Just like when joining a Minecraft server, you just need a specific address and port and voilà. We can implement almost every client-facing feature we want to implement with this model.

It also seems like a system simple enough that later on, if we do decide that we want federalization, we could pull off relatively easily.

Cons

Intuitively, guilds don't talk to each other, as they are separate communities. But on Discord for instance, there is this possibility of following a guild's channel in another server that you administer. If we go with this model, then we cannot implement such a feature. That is, unless we reconvert it into a federated instance model, which again appears relatively easy to pull off at first glance.

Alternatives

You tell me! :)

Additional information

No response

Checks

• I have checked for existing issues about this, and did not
  find any.

[Corbanator]

I think it's worth asking how Direct Messaging would work without a Federalized system, as there is no home server for any given user to store their direct messages in. I'm sure there's a solution, but how hard a solution is or isn't is definitely something to be considered.

[TudbuT]

Direct messages would have to happen through the same centralized auth server, or they would have to happen on some server the users choose for them, I think. This'd be a pretty weird system as users have to choose a server each time, so I would probably say this'd be done in the auth server in a non-federation protocol.

[TudbuT]

with GitLab however, the authentication is managed by the instance, so you need one account per instance.

I would just like to mention for those who haven't heard the previous discussions: Only one account would be needed because people have a home server from which they can do everything they would be able to do on another server, on any other server. GitLab is not federated (content from one instance is not accessible from all others). If we do federation, only one account will be required, no matter how many instances you want to chat on.

[Coca162]

I think this brings into question the scope of the project and its goals. I've always seen this project as focused on the frontend much more then the backend, to the point where I initially proposed not making a backend at all and using some other platform's backend. This was due to the project's focus on getting rid of bloat from things such as electron and instead making simple code which has high performance. Such issues are not as common in backends.

Keeping that in mind if we need a backend then I support one which is as lean as possible. Which means I am not in favor of any decentralized features that add extra unwanted complexity.

[Speykious]

Which means I am not in favor of any decentralized features that add extra unwanted complexity.

I wouldn't say decentralized features necessarily add unwanted complexity. I believe it's possible to avoid over-engineering stuff in pretty much every domain of software development. Although I admit I don't know how much engineering is too much for backend, since I don't have as many bad experiences with bloated software on that front.

That said, as I've expressed before, we can start with simple isolated instances that we may augment with federation later.

[Coca162]

I believe decentralization would have to be so fundamental to the backend that simply adding it on later on would be a really bad idea. Allowing the client to be on different instances? Sure! But attempting to somehow make these instances talk to each other is going to be a massive challenge which requires a high amount of discussion before a lot of stuff is built up. This is both true for a federated and auth server approach.

[TudbuT]

I believe decentralization would have to be so fundamental to the backend that simply adding it on later on would be a really bad idea. Allowing the client to be on different instances? Sure!

I also think this is the best idea.

But attempting to somehow make these instances talk to each other is going to be a massive challenge which requires a high amount of discussion before a lot of stuff is built up.

That might be true, maybe the non-federated approach is easier here.

This is both true for a federated and auth server approach.

Here's where I don't quite know what you mean: The auth server means you don't have any servers talking to eachother besides the main servers talking to the auth server.

• server -> client | id
• client -> auth server | credentials, id
• client -> server | check request
• server -> auth server | id
• auth server -> server | "ok"
• server -> client | token
• client now makes further requests to server with the token

[Coca162]

Here's where I don't quite know what you mean: The auth server means you don't have any servers talking to eachother besides the main servers talking to the auth server.

This is a good point, however how will direct messages will work in this if the servers are not talking to each other? Would the auth server have to handle it? And if so are there any ways to allow for scaling of the DMs infrastructure if the load on a single auth server is too much?

[AshesOfEther]

I think, without federation, the best choice would be for the two users to just pick an instance to use for it. Having an auth server is a compromise that minimizes centralization, while keeping some of the convenience. Either people stick to the same big auth server, in which case we have a lot more centralization now that DMs are routed through it, or fragmentation occurs and we remain decentralized, though we lose the benefit of having a singular auth server.

Additionally, making it handle messages would essentially turn in into an instance on its own, hugely increasing its complexity. It would need to do a lot of stuff that instances already do. At that point, it seems easier to just make instances do the extra task of handling DMs, and have users make a choice of instance same way they already do with guilds.

[Coca162]

I could see there being some complications with the DMs being done like this on the frontend but I do think the @tobiassn approach would be the best.

I'm personally also leaning more towards auth servers then before. Since in the context of scaling it would be HIGHLY beneficial.