Decentralize your world.
There is of course #mastodon as federated social media.
There is good old #email as federated postbox (as long as not everyone uses GMail).
There is #peertube as a federated video platform.
There is #Riot / Matrix.org as federated group messaging.
There is #XMPP for federated 1on1 messaging.
And there is #nextcloud as federated cloud storage.
In theory most services are already federated. We only miss more users :)
Thats an interesting question, searx is a #openweb project that fits the #4opens using common, technology. For example we are trying to get a search plugin for mastodon and the #OMN linking project, anyone can use this on there instances of searx. begs the question what "federation" is/not.
I hope you double check your definition of federation.
All listed services support federation.
Nextcloud interconnects between Nextcloud and OwnCloud instances using their fedeated-sharing feature.
XMPP is explicitly made for federation and the s2s protocol connects between XMPP instances.
Peertube connects with MediaGoblin and other Peertube instances using activityPub.
Just do a tiny little bit of research on these Protocols/implementations. ;)
@sheogorath @hund Also, IRC was /designed/ to be federated, but the protocol design was too trusting of instance admins (ircops) - an ircop could elevate themselves to channel op and start kicking users from a channel, even if they were on another server.
However, the fix for that was, instead of making ops only able to affect their own server's users, to implement policies of only federating along common policy lines, so federation became load balancing instead of decentralization.
@TankeSkud Yes and no, On one hand yes, search engines can probably be federated, on the other hand I wouldn't call Yacy federated.
Yacy calls itself a P2P search engine and other than federation, P2P starts to build up mirrors of content to keep it online. While in case of Federation you have an original source and owner of data and when this owner goes down the data is gone.
Also in usual P2P networks you address content (with a hash), while in federated networks you address id@source.
@smakian Phew, that's no easy question. There is OpenEvent but I wouldn't consider it as usable for non-tech people.
Also it's not build for federation. Maybe someone is annoyed enough that he or she starts to work on an event platform that supports OpenID for customers and maybe also publishes its feed via ActivityPub ^^
Apart from that, with some luck maybe another person in the Fediverse already has a solution and will tell it to us?
@sheogorath I'de say we need a nice, federated code hosting and issue tracker.
There is a feature request for GitLab already: https://gitlab.com/gitlab-org/gitlab-ce/issues/44486
So, one can hope.
reportedly already a feature in pagure.io/pagure
@rysiek @deejoe Ha! looks like I found it: https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request
As well as a (from my perspective) was more practical point of view to the issue: https://github.com/go-gitea/gitea/issues/184
When you check my recent history, you'll notice I have a very own opinion on Telegram.
Anyways, yes and no. Telegram works fine with something like 5 groups and 10 private conversations. But I'm currently working with more than 50 large group on riot and 20-30 private conversations (in my case on signal).
When you see how Telegram organizes these group and private conversations you die without pinning stuff.
Here I prefer 2 applications instead.
Ever had very active chat conversations? It starts with the point that group and 1on1 chats are mixed up and reordered by chat activity.
Followed by the fact that you may want to be in a group but put them on low priority because you sometimes reach out there for help but you are in general not too interested in it. Etc. Also I don't know any company putting their interal conversation on telegram. But I know people who do that on matrix.org ;)
Technically every conversation is a group in Matrix because your 3 client devices and your partner's 2 devices already make a group of 5 devices, even if there's only two accounts involved.
Everything can be end-to-end encrypted in Matrix with an *audited* protocol (meg-olm) and opensource implementation.
While I agree from my perspective right now (as everything is in beta) I prefer to use a messenger that runs #e2e encryption by default for IM.
Also it's still something I like to split anyways as Matrix is connected to all the projects I'm working on, while a separate app for my private chats with friends and family keep distraction away. Sure, this could also be solved by multiple accounts, by why not keep it UNIX :)
For 1:1 conversations there's a gazillion alternatives with E2EE that have acceptable UI (by now) and good crypto. (Namely Signal, though the “desktop client” as they dare to call it is a terrible abomination.)
For encrypted group chats there is no federated, group E2EE capable alternative.
@desikn I guess I understand what you want to have :D
You want federated Google services, right?
I don't think that will happen because the way Google services are built are way less complex than how we build stuff for federation.
In case of Google you have a company with decisions and a made up direction.
In free software you have tons of political and technical discussions. Free software development is way less efficient but that doesn't mean it's bad. But it means you won't get this soon.
@amiloradovsky As mentioned in another answer to my original toot:
searx is a #selfhosted meta-search engine. So neither federated nor independent .
And as you can see in the results page, they are very often just taken from Google and/or Bing.
@sheogorath That..really isn't true from my experience.
XMPP has excellent group chats, and the UI is about what you'd expect coming from Matrix or IRC (though most older clients separate the roster from the chat window, similar to Steam). It just separates people from MUCs.
Matrix on the other hand, simply does not differentiate. While this serves to simplify things in some ways, it also complicates them in others.
@bmt Well, one intent behind this list is the factor that service can stop to try to be compatible to "every state''s law" and instead you have instances inside a state that run under the local law.
For those who explicitly don't want an instance in their own country for what ever reason, well, influence your politics, and you can still sign up on another instance, but not everyone has to fulfil every state's laws :)
@sheogorath Signal is the only free and secure IM with a passable UX I've seen so far.
I have some hope that Signal will drive some adoption community because it made design trade-offs which—while at adds with some of us neckbeards—facilitate mass adoption. Yes, I'm talking about being phone number based and using GCM for message delivery.
Nobody would use Mastodon if there weren't native clients fir iOS and Android. Even more would use it, especially the mire active users, if there were native client applications for Windows, macOS, Linux and BSD.
Any Webinterface is a terrible UX compared to real native applications.
@gutigen In this case you may want to have a look at: https://docs.nextcloud.com/server/12/admin_manual/configuration_files/federated_cloud_sharing_configuration.html
It is federated, no worries, I use this feature on a daily basis ;)
@sheogorath this list is so handy! Thank you for sharing!!
@tofeo Yes, I didn't mention a lot on this list.
I think the intention was more to show the span of different service types more than list all possible alternatives :)
I hope you understand that the space is limited in 500 characters and this way, not everything could be mentioned ^^
@jringram Well, decentralization in first place means moving away from a central point/instance/entity. Like moving away from GMail or Facebook.
Federation means that independent service providers interconnect and this way communication across providers is possible. Like email providers and your ability to send emails from mailbox.org to Gmail or Mastodon so you can communicate between instances.
There is also P2P but that's a completely different story ;) (as I have only 6 chars left)
I agree that @matrix is able to do 1on1 as well, but right now from my perspective the #e2e encryption (specially the requirement to approve every device from the other side) makes it too complicated for a lot of users.
Here I would rather recommend apps like Conversations which may also use #GPG which can wonderful adapt the email workflow. And this way easily verify identities over multiple devices.
Well, that's why I mentioned GPG. Which uses traditional signing ways. Or if you go for something like Signal, you can mark keys of people you met face2face as trusted.
So even unverifed e2ee is more than plain transport enryption. Why? Because (in usual e2ee-featuring clients) you get notified about key changes after "accepting" one. So it's harder to MITM and established e2ee even when the keys are unverifed using a 2nd channel.
@classyguy It depends a bit on what you are about to do. for me Matrix is focused on group communication (like every conversation is a group) while XMPP is focused on 1on1 conversations.
To be honest, I don't use XMPP myself, instead go for signal, but for this list it seemed to be not the right choice, so back to good old XMPP.
Also in my opinion XMPP is a bit better with e2ee by default than Matrix is right now(!) as it's not enabled by default and a bit too complicated for non-tech people.
If you talk about architecture:
If you talk about enduser documentation, there are some videos but I don't think there is already something written about really "how to use it" :D
No worries guys, I'm aware of that. But given to the case, that I wrote this on Mastodon with less than 40 followers, I neither expect this to spread so far, nor did I have enough space/characters to list all the different implementations without omitting the rest of the list.
It was a post out of a mood and neither was intended to be complete nor completely correct, so feel free to add tips or improve it by rewriting :)