It would be awesome to integrate Codeberg with some Open Source chat/social platform, e.g. Gitter which is Open Source: https://gitlab.com/gitlab-org/gitter/webapp
I would try to have a look at setting up Gitter, but probably won't get around doing this in the next days/weeks.
This would be great!
Yes, gitter would be great!
Gitter has a "Direct Chat" feature just like all other social networks. (Except GitHub.)
What about a Matrix/Riot server as an alternative? Although it's not quite as beautiful and mature as Gitter, it's federated (so it can be used for everything messaging-related instead of just for some projects), end-to-end encrypted, and supports communities with rooms just like Gitter.
My recommendation is XMPP (Jabber)
XMPP (Jabber) is a open protocol for instant messaging.
See for example https://tools.ietf.org/html/rfc6120 for more information about XMPP Core.
XMPP is extensible. Extensions are defines in XEPs:
https://xmpp.org/extensions/
MUCs are Multi User Chats defined within
XEP-0045: Multi-User Chat https://xmpp.org/extensions/xep-0045.html
A free and open-source XMPP chat client in your browser
https://conversejs.org/
Android Client for Smartphones
https://conversations.im/
Desktop Client
https://dino.im/
Encryption via GnuPG or OMEMO.
Hi there 😁
I think adding any form of private messaging to codeberg would really help enforcing Code of Conducts early on.
I'm currently planning to add a CoC like this one to a project, but the first stage of enforcement currently seems impossible via codeberg, as there isn't a non-public way to make contributors aware of improper behaviour. At least that I'm aware of and if the mail address is hidden on the user profile.
No preference on the way it's implemented on my site - Gitter, Matrix/Riot and XMPP all would do the trick I think. But I wanted to share this aspect as I think it is important. :-)
good one.
If you add chat, then it would be really cool to have something that ties into codeberg. Otherwise there is no real benefit of having that come as part of the package IMHO.
Maybe have a matrix server that creates a room for each project with a bot that reports on changes happening in the project or something.
I created a small project (just a kind of prototype so far). This is a XMPP Bot with a Codeberg Module. The Bot is listening on a TCP Port. The Codeberg Webhook can be used to call the bot. The bot will post information to a Multi Use Chat (MUC).
Example:
[18:43:42] hawkbit-bot: Kommentar von DebXWoody : Konzept - Anwendungsdesign Module xmpp-messenger/hawkbit-bot#19 (comment)
It's not ready for production, but it's working.
https://codeberg.org/xmpp-messenger/hawkbit-bot/src/branch/master/src/modules/CodebergModule.cpp
Sounds cool, need to check that out
@hunger I think with RocketChat (which seems like the most potent option if we want to provide a chat for Codeberg instead of a full general-purpose messenger server, which is quite hard to maintain) it should be relatively easy to just forbid creating new rooms for people, and instead creating them automatically through the Gitea repositories.
Then I'm imagining that "Chat" could be just another option that can be enabled for a repository, like "Wiki" or "Issues" right now.
...couldn't find codeberg on Matrix.
There is now a #codeberg.org:matrix.org room (Anybody here knows how grabbed the #codeberg:matrix.org ?) – is there an IRC room that would make sense to be bridged?
I'm surprised codeberg even being interested in microsofts github chat system and NOT Matrix.
o_0
It would be very nice to have a XMPP MUC for the commmunity to share information about git / codeberg etc.
Something that both has a public/established protocol (for mobile/desktop clients etc), and can be integrated via HTML widget for example as tab right beside issues, pull requests and wiki would be really cool.
(Anybody wants to code a xmpp/matrix/rocket/irc/... chat into a gitea tab? PR welcome!)
(Anybody wants to code a xmpp/matrix/rocket/irc/... chat into a gitea tab? PR welcome!)
That's exactly what I'm trying to do with https://codeberg.org/Codeberg-Infrastructure/gitea-rocketchat-sync, but it's a lot of work (at least if it should work as seamless as I'm planning it to work) - if someone wants to help out with the Rocket.Chat integration, I'm happy to work together.
I'm not sure, maybe https://conversejs.org/ can be integrated on websites.
I'm not sure, maybe https://conversejs.org/ can be integrated on websites.
I don't know anything about this one, but a pure client-side JS client seems to have some benefit of minimal impact on the gitea implementation?
@varbhat convos is a IRC chat if i understand right - I think xmpp or matrix is the modern way to go :)
How does any of these options work with user management of gitea's users?
@6543 Yes. Convos is IRC . That means I/anyone can use any well established IRC clients to communicate.
It's not just plain IRC. It adds user favicons,image/file upload , etc. Just a reminder that it adds many features to plain IRC to make it appealing.
Also large no. of software communities live in IRC . You can directly contact them within convos.
If not convos,I would route for matrix. I think that xmpp is way too fragmented.
Everyone has a different favorite chat solution. Eventually it is better if each projekt owner decides itself which chat solution he wants to use (in the end, it could be a link in the readme). I would never use Matrix while others would never use XMPP.
I think that codeberg could host one/ multiple possible solutions which one could use from a codeberg project BUT I don't think that Codeberg has the ressources to maintain such things. If they would host such solutions, then it could be an idea to allow a sign in using the git credentials. But I think that's really out of the scope of Codeberg.
A nice thing could be a public chat room related to Codeberg in general (not to a specfic project hosted at Codeberg). This could be multiple rooms at existing servers in the different ecosystems (XMPP, Matrix, IRC, whatever), eventually bridged together if that works good.
Another idea would be to add a feature to gitea so that project owners can add a link to a chat which is shown as another tab within projects. But this would be something to ask for at gitea and not here.
Another idea would be to add a feature to gitea so that project owners can add a link to a chat which is shown as another tab within projects.
This is the only scenario that makes sense.
But this would be something to ask for at gitea and not here.
It seems the closest related issue is https://github.com/go-gitea/gitea/issues/5469 ?
I don’t think that Codeberg has the ressources to maintain such things
Technically, we do. But spam and similar issues might become a huge problem, which can probably only be solved by disabling federation, as we then have control over the users. We'll have to think about if we want that, in any case it will make sense though to allow repo owners to enable it on a per-channel basis.
I'm for Codeberg providing a single service that reflects repos and the access rights to those repos (so, being completely seamlessly integrated), and integrating it into Gitea as the default for a user-providable chat iframe tab (as discussed above).
A nice thing could be a public chat room related to Codeberg in general (not to a specfic project hosted at Codeberg).
See #codeberg.org:matrix.org (#38 (comment))
So, regarding possible products we could use for the Codeberg-provided chat service - Rocket.Chat has:
If someone has another application that offers all those features (especially the last two, as they're basically essential for a direct integration with Codeberg), I'm open to it - I'm seeing the following problems with the suggestions here though:
So, Rocket.Chat is extremely easy to integrate compared with all other solutions, and a single solution for all our chat needs - I'll be working on that in the next month. Matrix or XMPP are way more complex to implement, but I'm open to actual ideas on how to implement it with most of the features I've listed above.
I don't consider XMPP fragmented, but for the usage within Codeberg something which is intended for the usage within the Browser would be a good idea. On the other hand, this does not make it easy to use one client for joining multiple project groups if they are not all hosted at Codeberg - for this, using a XMPP/ Matrix/ ... room could work better.
[...] for the usage within Codeberg something which is intended for the usage within the Browser would be a good idea. On the other hand, this does not make it easy to use one client for joining multiple project groups if they are not all hosted at Codeberg [...]
Embedding a public protocol client in UI should enable both, user synchronization is a challenge tho (unless the server is part of gitea itself or can authenticate users by other means with gitea, for example using the swagger API).
@hw why not use Codeberg as OAuth 2.0 provider and allow only registrations throu OAuth on the ChatServer ?
Integrating Matrix/XMPP/IRC/... into gitea is out of question - but if an API is needed to integrate one of thouse witch do not exist just tell me :) (+ and open an issue to have track of ;) )
Yes, OAuth2 would be the authentication idea when using Rocket.Chat, that's why it'd be that easy - XMPP would be another possible method, but I haven't used it at all, hence that would be only possible if someone else wants to work on this.
would this work? sounds perfect
hmm so RocketChat 👍 - with Codeberg/build-deploy-gitea#17 I think this will be well integrated 🎉
looking forward to https://chat.codeberg.org/
ideally i would implement this using the PINE64 approach which is implementing IRC, discord, Slack, Matrix that are bridged together so if user sends message for example on IRC it shows up on Discord and Slack at the same time where these bridges take negligible amount of processing power to satisfy everyone as they can use their preferred chat client.
This is how it would work in practice(censored for privacy):
image
In general i think we should use end-to-end (E2E) based clents with end-to-end-encryption (E2EE) where XMPP seems as best option in terms of privacy as IRC doesn't have a reliable way to implement E2EE.
The issue with this proposal is that it creates a maintainance overhead as now we would have to maintain all the communities in which case i recommend leaving the communities to be community maintained with codeberg maintainance and guidance by specifying Code Of Conduct (CoC) and resolving reports in case the self-assigned administrators (or running adminless server managed through bots which would be nice and also needs negligible amount of system resources) are unable to resolve the issue in accordance with CoC or resolve the issues within a repository on gitea in case the CoC needs updating.
FWIW in terms of required processing power this can be set up using a cheap single board computer which is what PINE64 is using.
Also for what it's worth discord has E2EE implemented through it's community more info on https://github.com/Kreyren/discord-server/blob/master/encryption-setup.md
Also having a chat within gitea itself might be worth consideration, i think we could fork the implementation from minds https://minds.com/ which is also using Golang?
End to end encryption in public chats is not useful.
I wouldn't use a chat service when I would know that the contents are sent/ bridged to Discord and Slack. There are reasons why I'm using a german git hosting.
End to end encryption in public chats is not useful. @jonas-l
Disagree as keeping the data on the remote server makes them possibly redistributable especially for european citizens without being aware of GDPR violation which for example Discord's founder is known for assuming simmilar situation in it's previous discord-like service namely mentioned in a source https://www.reddit.com/r/Mcat/comments/9grnx3/warning_about_discord/ quoting:
Jason Citron, founder of Discord, had previously founded a company called OpenFeint, which was sued for extreme privacy abuses – illegally harvesting and selling data.
Quoting Courthouse news https://www.courthousenews.com/gamers-say-openfeint-sold-them-out/ and the provided reddit post:
The OpenFeint mobile gaming network collected data and personal information from its users’ cellphone-linked profiles and sold the information to Internet application developers, according to a federal class action.
Lead plaintiff Matthew Hines claims Openfeint accessed, monitored and stored the unique device identifiers for mobile devices along with personally identifiable information such as a user’s exact GPS location, Internet browsing history and Facebook and Twitter profiles.
OpenFeint’s business plan included accessing and disclosing personal information without authorization to mobile-device application developers, advertising networks and web-analytic vendors that market mobile applications, according to the complaint. The company acquired such information covertly, without adequate notice or consent, involving 100 million consumer mobile devices.
I wouldn’t use a chat service when I would know that the contents are sent/ bridged to Discord and Slack. There are reasons why I’m using a german git hosting. @jonas-l
Thus reasoning for E2EE so that even if companies like allegedly Discord (for reasons provided above) and knownly Slack as mentioned in their Privacy policy as:
For example, we may improve search functionality by using Other Information to help determine and rank the relevance of content, channels or expertise to an Authorized User, make Services or Third Party Service suggestions based on historical use and predictive models, identify organizational trends and insights, to customize a Services experience, or create new productivity features and products. https://slack.com/trust/privacy/privacy-policy?nojsmode=1#information
Further indicated by them wrapping all urls in trackable extentions and allegedly logging which URL was visited by which user, when and how.
Redistribute the date they woudn't be able to sell the information as they don't have the decryption key unless they somehow obtained it.
There are reasons why I don't want bridges to no-EU services. You don't have to explain how trustworthy they are.
The problem is that anyone could just join a public chat - so there is nothing to encrypt because anyone who wants to see the content can join (which no one would notice in bigger rooms).
@jonas-l What do you propose then? I personally don't think that we should restrict the end-users on what services are being used as a community portals so that end-users are not forced to use service that they are not convident with.
Also based on my experience if someone wants to use their preferred service they will do whatever they can do make that happend i.e i had a community member preferring discord above IRC and he made a project that runs bunch of weird wrappers and macros that bridged the IRC content from a 3rd party in his discord channel.
What would you do? End to end encryption works, but briding multiple systems where each uses end to end encryption is not something which would work (without bridges which decrypt everything and thus destroy the end to end aspect).
The project owner makes the rules and decides in the end which service is used/ services are used. I would add to the rules that it's not allowed to bridge it somehwere else.
When bridging multiple systems, then there are the biggest privacy issues because every service gets the data.
I would not use IRC or anything else without providing a web based frontend. Otherwise it could get too uncomfortable and lead to such activities like builiding a bridge even if the code of conduct of the channel forbids it.
What would you do? @jonas-l
First thing that comes in my mind would be to look for an excuse to write rustlang program and implemented the bridge that way with cryptography using oversalted random generator and handled the communities adminless through CoC and if required assigned community members with option to file a complaint to codeberg about an unwanted behavior in these + WebUI for chat.codeberg.org and seeing if we can fork the minds chat to be optionally available on the main website.
There is also a concern of giving the decryption key to bad actor for which i would make a different channel and gave access only to codeberg members and trusted users through a process designed to limit the leak of data with auto-kicks if the user doesn't sent a message in the channel for X amount of time as a counter-measure for log-bots.
The project owner makes the rules and decides in the end which service is used/ services are used. @jonas-l
Owner decides on implementation, community on whether it is going to be used :p
would not use IRC or anything else without providing a web based frontend. Otherwise it could get too uncomfortable and lead to such activities like builiding a bridge even if the code of conduct of the channel forbids it. @jonas-l
If we decide on only IRC there are clients that provide an UI on the web i.e Kiwi which is for example available on https://webchat.freenode.net/, but FWIW if you don't have trust in your system then there is probably something really wrong with it.
FWIW i personally hate webUI for IRC as that makes it quite annoying to manage at some scenarios i.e. using only Terminal User Interface (TUI)
FWIW i've created irc.freenode.net/#codeberg if you want to join :p
UPDATE: gitter is moving to matrix ...
UPDATE: gitter is moving to matrix ...
What are your thoughts on gitea integration? (something like a configurable per-project chat tab right beside the wiki maybe?)
I think that would be great, maybe for now directly using Matrix and later switching to Gitter? It seems like they don't have switched completely yet. The effort should be the same with Matrix and Rocket.Chat.
Also, notifications are a problem when offering more than one service - I'm working on that.
FWIW, I've added Gitea integration with DexIDP, which allows for logging into Matrix with a Gitea account.
This issue hasn't seen any recent activity, and I don't think we should keep it open, since it is not going to be implemented from the current core Codeberg team. As Codeberg, we don't need to host every service, and many projects have adopted their Matrix groups on other servers. Also, we're providing a Projects on Codeberg space for visibility in Matrix.
That said, if there is further interest in pushing this, please find a group of maintainers (2+) who will take the responsibility for running this service and working on the necessary integrations. Providing the computing resources and supporting the way can be done from the existing Codeberg maintainers.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?