go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
45.42k stars 5.52k forks source link

Index public repos of gitea instances #7853

Open sapk opened 5 years ago

sapk commented 5 years ago

In order to promote projects that use Gitea, I suggest to setup a system that list public repo of multiple instance.

This would be a separate project that leverage gitea api to retrieve information from Gitea instances.

The url could be like index.gitea.xxx or explore.gitea.xxx

The list of instance could be maintain by PR on the new project. That way we index only requested instances.

lafriks commented 5 years ago

I was thinking already about creating such site... I even registered domain hubco.io for this :D

lunny commented 5 years ago

I like a union concept. When a gitea instance accept another gitea instance, then they will exchange public repositories for each other. And we can list all repositories on both sites. We can add a new top menu named indexes. You can search repositories by name and description.

lunny commented 5 years ago

The feature could be as a part of gitea, it should not be a standalone repository. Furthermore, we can add the placeholder repositories on repositories search.

So that, there is no center server. Index site is still a center server.

lunny commented 5 years ago

We could add a table named RepoIndex which only have RepoName, RepoDescription and RepoLink or another column topics. Then all repositories search will search this table but not repository.

sapk commented 5 years ago

The feature could be as a part of gitea, it should not be a standalone repository.

I fear that it doesn't scale well in gitea.

So that, there is no center server. Index site is still a center server.

In this case, I think that is good to be centered (like a marketplace) and it is not needed for using Gitea. This should be an OSS so anymore can run it but having a "trusted" central point is important for publicity.

Later, when we have more insight on federation and better codebase this can become obselete by integrating it in gitea. In fact, this can provide experience for federation without impacting the security of gitea instances. (ex: rogue instance that send/expose malicious crafted payload)

lunny commented 5 years ago

@sapk that likes a search engine for git repositories, not only for gitea but also all git repositories on the internet.

sapk commented 5 years ago

Yes you can see it like that but the main goal is gitea. If other git platform would like to be listed and do the implementation I wouldn't see any problem.

kolaente commented 5 years ago

I like the idea, but I think it should be "opt-in" for either the whole instance or individual repos.

sapk commented 5 years ago

Rethinking about it and how to implement it (and variable time I have), I feel we could do a simple awesome-gitea (https://github.com/sindresorhus/awesome/blob/master/awesome.md). That way only proposed project are listed.

Edit: the other advantage is that it can be directly forked/mirrored across various instances.

sapk commented 5 years ago

As an example: https://gitea.com/sapk/awesome-gitea/src/branch/master/README.md

lunny commented 5 years ago

@sapk I like your new idea than before. If we can generate the list from the Gitea API and post PR to this repositories and all other gitea instances could mirror this repositories.

strk commented 5 years ago

See also https://github.com/go-gitea/website/issues/70

sapk commented 5 years ago

I made a poc with: https://explore.sapk.fr/#/ (go + js/vue + elasticsearch) It is not perfect but a good POC. I will release the sources.

kolaente commented 5 years ago

@sapk Awesome! Did you just query the api of the instances and then put it in elasticsearch?

sapk commented 5 years ago

@kolaente exactly.

strk commented 5 years ago

@sapk Awesome! Did you just query the api of the instances and then put it in elasticsearch?

Query the API of which instances ? How did you find instances ?

--strk;

lunny commented 5 years ago

@sapk awesome!!!

theAkito commented 5 years ago

@sapk You must be doing something right if @lunny himself cheers you.

sapk commented 5 years ago

@strk They are hard-coded in code currently. I found them via Twitter or some Google specific search.

The main issues are :

sapk commented 5 years ago

The source-code is available on gitea.com : https://gitea.com/sapk/explore https://gitea.com/sapk/explore-webapp

sunjam commented 3 years ago

16758 allows public instances to be indexed via nodeinfo metadata.

https://github.com/jhass/nodeinfo

trymeouteh commented 3 years ago

+1 for a public list of gitea instances

MoralCode commented 2 years ago

I havent looked into this too much but i recently found https://forgefed.org, which seems to mention that gitea is working on implementing it.

In my relatively ilittle amount of research it seems like this should allow any gitea instance to federate with other instances to see not only each others repositories, but allow their users to fork, add issues, and make pull requests on their own instance, while also communicating this information back to other instances so that these issues and pull requests can stay in sync.

hickford commented 1 year ago

You can find some Gitea and Forgejo instances using search engines:

milahu commented 10 months ago

tor-hidden gitea instances

add onion git remote

cd your_repo
git remote add darktea.onion http://it7otdanqu7ktntxzm427cba6i53w6wlanlh23v5i3siqmos47pzhvyd.onion/your_org/your_repo
git config --add remote.darktea.onion.proxy socks5h://127.0.0.1:9050

note: this requires a running tor client, providing a socks5 proxy on 127.0.0.1:9050

sudo systemctl start tor
manito-manopla commented 8 months ago

Do you mean something similar to mastodon? Because if so, I agree with the idea that Gitea can be a federated network, although the instances are different, users can follow each other and contribute to the repositories of others that are in other instances without having to create an account in those respective instances