Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Federation for organization, repositories and users #1612

Open
jonasfranz opened this issue Apr 26, 2017 · 43 comments
Open

Federation for organization, repositories and users #1612

jonasfranz opened this issue Apr 26, 2017 · 43 comments

Comments

@jonasfranz
Copy link
Member

@jonasfranz jonasfranz commented Apr 26, 2017

See https://owncloud.org/features/federation/

I would like to see a feature like the federation feature of next cloud. It gives the ability to share repositories, organizations or users between multiple Gitea instances.

This has the advantages that business users could share their projects with other companies. This feature would reduce the management and administrativ overhead.

This makes it easier for beginners to start with Gitea.

It could uses the "Mirror"-feature of Gitea.

@kolaente
Copy link
Member

@kolaente kolaente commented Apr 26, 2017

It would probably be enough to support federated repositories

@jonasfranz jonasfranz changed the title Federated organization, repositories and users Federation for organization, repositories and users Apr 26, 2017
@jonasfranz
Copy link
Member Author

@jonasfranz jonasfranz commented Apr 26, 2017

@kolaente The federation feature make explicitly for users sense. If you want to share repositories you should use the mirror feature. But is would be very convenient for the project manager to add users from other git instances.

@strk
Copy link
Member

@strk strk commented Apr 26, 2017

See also #184 (is this a duplicate of that?)

@kolaente
Copy link
Member

@kolaente kolaente commented Apr 26, 2017

@strk kind of, but i think this one goes further

@jonasfranz
Copy link
Member Author

@jonasfranz jonasfranz commented Apr 26, 2017

@strk Kind of. But this issue includes a full integration of the federation feature for organization not only for pull requests.

@strk
Copy link
Member

@strk strk commented Apr 26, 2017

@jonasfranz
Copy link
Member Author

@jonasfranz jonasfranz commented Apr 26, 2017

@strk I agree with the idea to split this thing into many tickets. This ticket might be the user federation ticket doesn't it? But I don't want authentication for users of other platforms. I want the ability to add other users. The user will receive an invite from the user's Gitea instance. He will access the repository or organization from the his instance.

@strk
Copy link
Member

@strk strk commented Apr 26, 2017

@jonasfranz
Copy link
Member Author

@jonasfranz jonasfranz commented Apr 26, 2017

I think that the webfinger standard might be a good solution. But I think that it also could conflict with the git email of an user.

@strk
Copy link
Member

@strk strk commented Apr 26, 2017

@schmittlauch
Copy link
Contributor

@schmittlauch schmittlauch commented Jun 28, 2017

Regarding "what standard do we want to choose" I just want to point you to ActivityPub which is currently being finished by the Social Federation working group of the W3C. Some project implementing it (or currently working on that) are pump.io, Mastodon and MediaGoblin.

They don't use WebFinger though as they dislike the idea of a fixed .well-known path, but there are ideas about interoperability.

@jascodes
Copy link

@jascodes jascodes commented Feb 26, 2018

This feature will be truly game changer; keybase.io recently came out with client side encrypted git, thats also interesting.

@MatejLach
Copy link

@MatejLach MatejLach commented Apr 19, 2018

Just want to point out that ActivityPub is now done.

Adding support for AP would make Gitea compatible with a growing number of federated servers, such as Mastodon, PeerTube, NextCloud and HubZilla, broadening its reach considerably, not to mention a standout differentiator against GitLab.
It would also have the potential to dethrone GitHub as the go-to hosting for open-source projects, since most are here for the community pull request workflow that AP would allow in a decentralised manner, increasing privacy and eliminating a single point of failure for a large percentage of the free software community.

Anyway, my hope is this gets implemented, it has the potential to be revolutionary!

@tboerger
Copy link
Member

@tboerger tboerger commented Apr 20, 2018

As already stated within the chat, ActivityPub in go is a PITA because it's hard to do in a static language like go.

@MatejLach
Copy link

@MatejLach MatejLach commented Apr 20, 2018

@tboerger Interesting. The ActivityPub spec is quite inheritance-heavy OO, but that should be possible to model in Go with struct embedding, however as far as I know, there's nothing like serde in Rust (https://docs.serde.rs/serde_json/value/index.html), which simplifies things quite a lot, however there's some effort to implement ActivityPub in Go, which may be a good start since it not only already implements json-ld parsing, but also defines the core vocabulary for ActivityStreams.

What specific annoyances are you thinking of here?

@jascodes
Copy link

@jascodes jascodes commented Apr 20, 2018

@yookoala
Copy link

@yookoala yookoala commented Jun 4, 2018

Relevant proposal in gogs repository:
gogs/gogs#4437

In Gitlab's repository:
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

@cwebber
Copy link

@cwebber cwebber commented Jun 4, 2018

Hi! ActivityPub co-editor here. I'm fairly busy at the moment but I'd like to see this happen... if you need questions feel free to ping me, or ask in #social on irc.w3.org

@cjslep
Copy link

@cjslep cjslep commented Jun 4, 2018

Please do not hesitate to reach out to me on Mastodon for any questions/concerns/comments surrounding the https://github.com/go-fed/activity library that @Jas99 mentioned. I obviously have a vested interest in the outcome of the decision, but would happy to provide candid information about my experiences working in the go+ActivityPub intersection. I agree with @tboerger that implementing ActivityPub in go is a steep cliff.

@lunny
Copy link
Member

@lunny lunny commented Jun 5, 2018

Maybe we could create a new repository named index and set up the new domain index.gitea.io to do that?

@jonasfranz
Copy link
Member Author

@jonasfranz jonasfranz commented Jun 5, 2018

Why do we need an index server? @lunny

@jaywink
Copy link

@jaywink jaywink commented Jun 5, 2018

Would be awesome if we could have different projects discussing a common implementation of the ActivityPub protocol (ie using the same extension for verbs, etc). This would enable users of gitea, gogs and gitlab to work together seamlessly just like users of various social media platforms that federate can discuss seamlessly.

Could this be the place? -> https://github.com/git-federation/gitpub

@mrenvoize
Copy link

@mrenvoize mrenvoize commented Apr 23, 2019

11 months since the last comment here.. I'm wondering if there are still plans afoot?

@lafriks
Copy link
Member

@lafriks lafriks commented Apr 23, 2019

When there is some kind of standard agreed upon than yes

@nogweii
Copy link

@nogweii nogweii commented Apr 25, 2019

Current discussions are happening as part of the forgefed project, so follow along there if you want to know more: https://github.com/forgefed/forgefed

As @lafriks mentioned, once there is a agreed standard, then various projects can implement it.

@strk
Copy link
Member

@strk strk commented May 26, 2019

The correct URL for forgefed project is now https://notabug.org/peers/forgefed

@dessalines
Copy link

@dessalines dessalines commented Jul 26, 2019

Seems like this should be of prime importance now, considering github is now removing accounts of ppl from entire countries.

@jaywink
Copy link

@jaywink jaywink commented Jul 27, 2019

ForgeFed also now has a discussion forum. Would be great to get someone from Gitea involved.

@teotikalki
Copy link

@teotikalki teotikalki commented Dec 14, 2019

+1 for this. Working from a local self-hosted instance but not being isolated due to that choice would truly be the best of both worlds.

@jaywink
Copy link

@jaywink jaywink commented Dec 14, 2019

The ForgeFed working group would desperately need developers from the current forges to give comments: https://talk.feneas.org/t/working-group-instructions/196

@teotikalki
Copy link

@teotikalki teotikalki commented Jan 1, 2020

I'd just like to add that before Microsoft inspired a mass migration away from Github this wouldn't have been a killer feature... NOW it is. Less and less of the repos for OS projects that I'm researching are on Github now (MAYBE mirrored here).

I've read that ones Github commit history can read like a cv and that one of the reasons that the software world is so career mobile is that a person can self-teach valuable skills, EASILY DEMONSTRATE them (public github history), and thus qualify for better earnings/etc. If your contribution history is spread out over dozens of private servers it is FAR less visible/useful.

Also, any of those servers could go down at any time and that part of your history is now gone. A proper implementation of federated repositories would mean that I could participate in dozens of projects on dozens of instances (from my instance) and if they ALL went down I'd still have my 'federated git profile'.

@aschrijver
Copy link

@aschrijver aschrijver commented Feb 13, 2020

Linking to the ForgeFed roadmap (there's funding for those who'll work on it):

https://notabug.org/peers/forgefed/issues/87

@zyansheep
Copy link

@zyansheep zyansheep commented Aug 29, 2020

Perhaps, for a simple implementation, gitea could run an ipfs node in the background hosting local repository files (using ipns to point to the latest versions of the repositories). We could then have a simple gossip protocol implementation to find other gitea instances and get ipns hashes & preliminary data (stars, name).
The benefit to using ipfs would be when users on one instance want to view or fork repositories on other instances, it would contribute to hosting parts of that repository and make accessing the repo faster for network as a whole.

Using ipfs/ipns could also be used for distributing user data such as starred repositories, pull requests, bio, etc. each node would only store names & ipns hashes for users on other networks that the instance cares about and it would be trivial to request profile data for unknown users.

ipfs already has a go implementation and for instance discovery something like this could be used.

@remram44
Copy link

@remram44 remram44 commented Aug 29, 2020

There is no requirement for peer-to-peer storage here, what you describe doesn't seem required or even related to the problem at hand. I don't think there's interest in moving away from the Git storage format and transfer protocol. Maybe you should open a separate issue if you see a benefit here (I certainly don't).

@zyansheep

This comment was marked as off-topic.

@remram44
Copy link

@remram44 remram44 commented Aug 29, 2020

Can you just open a separate issue? This one is about something specific, and ForgeFed is already working on a protocol. Better yet, bring it up with them.

Piling on issues with comments like "what about ipfs/filecoin/blockchain" just seems rude.

@secondtruth
Copy link

@secondtruth secondtruth commented Oct 12, 2020

+1

GitLab is discussing this feature, too: https://gitlab.com/gitlab-org/gitlab/-/issues/6468

@cjslep
Copy link

@cjslep cjslep commented Oct 16, 2020

I pinged on the gitea dev discord a few days ago as a FYI, and have been proactively been trying to reach out to some of the folks behind ForgeFed, as with go-fed v1 being done & documented it would be nice to get an instance of gitea federated on ActivityPub though it is no small effort. I think the gitea folks are busy w/ other priorities atm. Unfortunately, I have had no success getting a hold of any of the ForgeFed folks. :(

Some of us in the ActivityPub community, coming off APConf2020, are experimenting with having a grassroots lightweight documentation process on a gitea instance and it feels weird to not be able to federate with it yet.

@delbonis
Copy link

@delbonis delbonis commented Oct 23, 2020

Git already has all the features necessary for decentralized mirroring, the only functionality missing is what's necessary to coordinate it, which is exactly what ForgeFed does. IPFS has no need to be here, and given how disastrously their mainnet launch went I'm not sure it's safe to get to deeply tied with other projects by Protocol Labs.

@thebalaa
Copy link

@thebalaa thebalaa commented Nov 22, 2020

I'm interested in collaborating on any of the existing initiatives. Let's try to put a working group together. Can suggest this Matrix channel for further discussion #noteworthy:tincan.community

@cjslep
Copy link

@cjslep cjslep commented Dec 29, 2020

FYI, I've kicked off the specific design discussion of federating via ActivityPub + ForgeFed in #14186. I would like specifics to stay there, so if anyone has more of the big-picture or strategy-level concerns ("why AP + ForgeFed and why not X"), this place remains intact for that purpose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet