Forge discovery

Hi,

I was wondering if the issue of forge discovery for a project isn’t something that should be somehow formalized.

The start of my reflexion came from noting that aweseome-selfhosted is not selfhosted. But I realized that even if it was self-osted, in a world with fedeproxy being finished, it would likely use github as a exposure mechanism (kinda in the same way people are pushing information to mastodon and twitter and facebook and newsletter).

In a more federated world, a project would need to signal there is potentially multiple forges.

Right now, we have discovery for nodes in the federation (like this PR ), but my understanding is that it exposes technical details from forge to forge.

What I have in mind is different. If I go to fedeproxy.eu, there is a human readable link to the repo, but that’s human readable, not machine readable.

Wouldn’t it be useful to have, since this would help to discover the forge to work on a project, and for example, automatically direct people there ?

I see several ways to implement that, from using a .well-known file for metadata to using wikidata for that (or both, fill wikidata from the file), but I guess it all depend on what is a project exactly, how does it map to website/name and to the concept of organisations in most forges (but not all).

2 Likes

This idea comes close to stuff I wrote on the SocialHub. See these topics:

It boils down to any one both human + machine readable schema / profile you can define, and then publish to a (federated) index server, for aggregation and to be reused elsewhere.

(PS. I started the delightful project which is similar to awesome lists, but only for FOSS, open science and open data resources, and curated sub-lists can be hosted anywhere, not just on github)

1 Like