Inspirations from other communities

While discussing fedeproxy with @dachary last week, we mentioned two projects that might be source of inspiration.


Which attempts to unify access to cloud resources which all have different APIs and it often finds a common denominator enabling applications that use this abstraction to be independent of a given cloud implementation, enabling the freedom to change cloud providers without changing the definition of a deployment (salt-cloud can be used as an exemple)

Here the Apache foundation is a warrant of maintenance and longevity of the project.


beeper is a proprietary chat solution for unified chat which is based on the open source components around matrix (, it promises to finance and maintain the bridges ecosystem (see the Bridges sections in the blog - Blog ).

For the list of bridges, which by definition are fragile and need to be maintained whenever the API or the chat service it bridges to change (and we know that can be often and unannounced, see the history of the twitter API).

Here we have companies that have a stake in keeping the bridges working because they provide a service based on that.


I don’t know if this has relevance for FedeProxy (maybe none at all), it is just an idea that popped up, so… just brainstorming.

Some days ago I outlined how Murmurations protocol could be used to auto-collect info that is now in files in federated app repo’s. See: Improvement to convention: Murmuration. The protocol now relies on a centralized index and schema library, which can themselves be federated.

FedeProxy might use something like this, where repositories are auto-indexed, and in that way model the entire “Topics” feature that you find on Github, but federated. Based on metadata that is posted to the index, all kinds of lists can be aggregated, and - as an end-user you just specify your interest in order to get them listed in your own code forge.


Featured on HN: Pulumi 3.0 | Hacker News

1 Like