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

@LecrisUT commented on GitHub (Jun 14, 2021):

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

@LecrisUT commented on GitHub (Jun 14, 2021): @lunny could you also add a tag as kind/federation? This can serve as an alternative approach to the ActivityPub/ForgeFed federation.

GiteaMirror commented

@anthonyjmartinez commented on GitHub (Jul 11, 2021):

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

Host my FOSS projects on my own Gitea instance
Do not wish to open registration on said instance, but would still like to have a direct path for community discussion, and
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.

@anthonyjmartinez commented on GitHub (Jul 11, 2021): 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](https://matrix.org/blog/2021/05/17/synapse-1-34-0-released), 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.

GiteaMirror commented

@LecrisUT commented on GitHub (Jul 11, 2021):

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.

@LecrisUT commented on GitHub (Jul 11, 2021): 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](https://github.com/Half-Shot/matrix-github) design.

GiteaMirror commented

@fnetX commented on GitHub (Feb 12, 2022):

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.

@fnetX commented on GitHub (Feb 12, 2022): 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.

GiteaMirror commented

@LecrisUT commented on GitHub (Feb 12, 2022):

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.

@LecrisUT commented on GitHub (Feb 12, 2022): 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.

GiteaMirror commented

@ShadowJonathan commented on GitHub (Feb 12, 2022):

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.

@ShadowJonathan commented on GitHub (Feb 12, 2022): 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.

GiteaMirror commented

@anthonyjmartinez commented on GitHub (Feb 15, 2022):

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

Host my FOSS projects on my own Gitea instance

Do not wish to open registration on said instance, but would still like to have a direct path for community discussion, and

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.

@anthonyjmartinez commented on GitHub (Feb 15, 2022): > 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](https://matrix.org/blog/2021/05/17/synapse-1-34-0-released), 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.

GiteaMirror commented

@ghost commented on GitHub (Apr 15, 2022):

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.

@ghost commented on GitHub (Apr 15, 2022): 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.

GiteaMirror commented

@LecrisUT commented on GitHub (Apr 15, 2022):

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.

@LecrisUT commented on GitHub (Apr 15, 2022): 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.

GiteaMirror commented

@ghost commented on GitHub (Apr 16, 2022):

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.

@ghost commented on GitHub (Apr 16, 2022): > 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.

GiteaMirror commented

@jcollie commented on GitHub (Jul 31, 2022):

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.

@jcollie commented on GitHub (Jul 31, 2022): 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.

GiteaMirror commented