[FR] Use matrix spaces for github like discussion and issue tracker.

[LecrisUT]

Use cases/Benefits

• Public users can join in on Discussion/Issues without having to create a local account
• Offload most discussion data to a system that is specialized for it. On gitea side would only have to keep track of room numbers, status and linkage.
• Support encryption and fine access control
• Discussions can become infinitely threaded

Discussion

• With the new space specs having been included in default matrix, and the upcoming thread support (currently only implemented in dendrite servers), matrix is becoming feature complete to support any features needed for discussions.
• Related project: Matrix-github-bridge (Half-Shot/matrix-github)

Potential design

• Each gitea server can manage their own space, with each repository having their own sub-space
• Each issue/discussion/PR would be their own rooms, with gitea keeping track of the metadata
• A gitea bot would handle automatic linkage and replacement of text, issue links etc.

[LecrisUT]

@lunny could you also add a tag as kind/federation? This can serve as an alternative approach to the ActivityPub/ForgeFed federation.

[anthonyjmartinez]

Thumbs up on this proposal from me. My present use case suits this quite well as I:

1. Host my FOSS projects on my own Gitea instance
2. Do not wish to open registration on said instance, but would still like to have a direct path for community discussion, and
3. Also run a Matrix homeserver tracking Matrix.org's Debian/Ubuntu repo.

That said, and playing Devil's Advocate a bit, there are rather extreme performance issues surrounding Matrix federation that were well highlighted during a large spam attack circa Synapse 1.37 (prompting 1.37.1). Furthermore, Spaces was introduced on the server side in Synapse 1.34, and from the traffic flowing through my instance it would appear that something like 15% of all homeservers are actively maintained to the point they even support spaces at all. Inclusion of such a feature, while desirable, should make certain it doesn't provide a vehicle to degrade Gitea performance on instances opting to use it.

[LecrisUT]

Good points, these could be handled from a design perspective.

For starters, we should still be using the gitea UI, so for those that do not have a matrix account or a server that supports spaces, they would still be able to register locally to that server, and appear as gitea managed bots on the matrix server. The ForgeFed issue seems to be getting some traction so they could also use that and we add a local bridge to combine these approaches.

For the performance, maybe we can use a stripped down version of dendrite or just the go-matrix client. We do not need to actually run the matrix servers ourselves, we just need to be able to run a bridge/bot service which should minimize the impact.

I may start hacking something together next month if nobody else starts it up. Or we can open up an organization on gitea or github and make an initial fork so that people can have a place to discuss and test. Also we should coordinate with Half-Shot/matrix-github design.

[fnetX]

I object to this issue, as running a Matrix server beside Gitea might

• introduce more complexity to self-hosters
• require more powerful machines than currently
• be more flaky as the internal database (personally, I saw some weirdnesses in Matrix, although I love it)

A big bonus of Gitea is that it's easy to self-host, it just runs, even on small VPS, Raspberrys etc. I think this will be lost if using Matrix.

Also note that this adds concurrent protocol implementations (Matrix + AP). I don't think this is a pretty good idea.

[LecrisUT]

Actually the idea is not to have a matrix server managed by gitea. The binary would only manage the bot, so it will not be more expensive than a client. I've looked in the backend a bit, and I agree it would be quite complicated to implement unless we can abstract the xorm part to allow for either protocol. For now it is ok if the matrix users are not federated.

[ShadowJonathan]

WRT automation, matrix has two methods of operation; "application services", and bots. The main difference is that appservices can control the server to a more advanced degree (being allocated a sub-portion of the namespace for it to manage), but it's also more intensive two-way local communication, so in this sense the gitea server would have to be on the same server (or close) to manage these rooms.

Alternatively, you can have the gitea matrix service be a bot, this'd then manage the rooms as an automoderator, and you could use remote matrix servers to manage your discussions, however, you lose your ability to easily manage ghosts on these rooms.

It depends on how gitea wants to manage or use matrix, if it wants to "outsource" all discussion for a PR to it, then it needs to also require every user to have a corresponding matrix server, and then every gitea user would have to verify their matrix account to their gitea account.

Alternatively, it could be used as storage, however, the gains here would be dubious, as you'll still have to expose the same discussions interactions on this room level to be able to take advantage of remote users.

In the end, it's about where the line is drawn as to how much matrix manages and is given responsibility for, and how much gitea wants close and ideal integration. Embedding a matrix server inside gitea (so it's endpoint doubles as a matrix server) could be a solution, but it may have trade-offs with the performance profile it would try to hit.

I recommend giving a look at Dendrite, and see to what extent it could be embedded, if that's the route forward.

---

Keep in mind that, as of right now, matrix has some limitations;

• you can't migrate a server (and all its data) to a different domain
• it's difficult to migrate a user (and all its permissions in rooms) to another server painlessly
• it's difficult to work with the matrix federation after you've installed a new server on the same domain, and it may display some errors and problems

These problems are intended to be fixed, but atm those are the limitations/difficulties.

[anthonyjmartinez]

Thumbs up on this proposal from me. My present use case suits this quite well as I:

1. Host my FOSS projects on my own Gitea instance
2. Do not wish to open registration on said instance, but would still like to have a direct path for community discussion, and
3. Also run a Matrix homeserver tracking Matrix.org's Debian/Ubuntu repo.

That said, and playing Devil's Advocate a bit, there are rather extreme performance issues surrounding Matrix federation that were well highlighted during a large spam attack circa Synapse 1.37 (prompting 1.37.1). Furthermore, Spaces was introduced on the server side in Synapse 1.34, and from the traffic flowing through my instance it would appear that something like 15% of all homeservers are actively maintained to the point they even support spaces at all. Inclusion of such a feature, while desirable, should make certain it doesn't provide a vehicle to degrade Gitea performance on instances opting to use it.

The devil's advocate position ought be stronger. Matrix is not stable. Neither is ActivityPub. The only mostly working federated system that exists today is email, and that too is generally a disaster.

[ghost]

Although this discussion has proposed some interesting ideas, I think this issue should be closed. Work has already started on ActivityPub federation for users, issues, and repos, and using the Matrix protocol as well for federation adds too much complexity.

[LecrisUT]

Since this is altogether a different implementation, I would suggest instead to decouple it from the planned gitea federation until we have someone who can work on it. Leave it open to indicate that it's still a possibility for the future.

[ghost]

Since this is altogether a different implementation, I would suggest instead to decouple it from the planned gitea federation until we have someone who can work on it. Leave it open to indicate that it's still a possibility for the future.

Sure, I'd be fine with leaving it open for now. Also FYI, the ActivityPub federation isn't planned, it's currently in active development.

[jcollie]

One thing to think about is the performance on your regular Matrix client if you participate in hundreds (or potentially thousands) of Gitea issues that are linked to Matrix rooms. My guess is that existing Matrix clients would start to suffer when handling more than tens of rooms. Users would need to unsubscribe from most issues which means that they would miss important updates.

[6543]

-> ForgeFed