Note: This discussion was imported from Loomio. Click here to view the original discussion.
Proposal: Change the federation protocol
There are really too many problems with federation. I didn’t look at how it works for the moment, but what I understood after a conversation with Raven/Florian is that every posts, images etc are copied on the other pods. That means that a pod with a single user who shares with 200 persons can have a very big size. The goal of Diaspora is to become really decentralized (a lot of pods with max 10 users), which means Diaspora has to be able to run on a really small config (max 1go hard disk). There is a problem here.
I don’t know who wrote the protocol and his knowledge about networks, but maybe we should do a big announcement and ask if some people with a big experience in networks want to help us. We should ask and listen to suggestions of developers all around the world.
Another possibility is to take a look on how Identi.ca, Friendica, etc… work.
Outcome: N/A
Votes:
- Yes: 0
- Abstain: 5
- No: 2
- Block: 0
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
While I agree that federation needs work, and have been talking to devs from other decentralized socnets, I think we have more pressing issues to be concerned about first. A rewrite will take a lot of effort to get going initially.
Before we start working on federation, I think we need to first get it into a layer.
Definitely +1 on the layer issue, that might actually allow us to (easier) run a alternative protocol simultaneously.
I think we should choose or make a protocol which works properly. After that, we have to build an API on it. And we will put the website on the API, so federation and the website will be separate.
For the moment, we can start by make the API on the current protocol, and interface the website with the API. This will really help to switch if we choose another protocol in the future.
@Fla: I’m pretty sure the API and federation are two separate things. Federation is not affected by the API, and vice versa. The API is how third-party clients talk to a server and use exposed functionality, federation is how different servers talk to one another to give the impression of seamless communication.
Agree, but servers can talk using the API like if they were a third-party, and if we do that, we have three layer : at the top, the client / the web site, at the bottom, the federation, and between them, allowing the communication, the API.
Bridging API with federation doesn’t strike me as a very safe idea. I worry that bridging the two like that could have some security implications. APIs are usually meant for applications, not necessarily entire other pods.
A good way to think of it (and I’m probably oversimplifying), an API is great for exposing functionality to a client. Federation, conversely, is great for sending out messages and data objects between servers.
We say federation protocol for a reason, it’s a protocol. Like HTTP is a protocol. You wouldn’t say HTTP is an API. You can create a library speaking HTTP that defines an API so the caller or client doesn’t have to know how HTTP works. And that’s what we need here, a library with a API so the rails app doesn’t need to know about our federation protocol. That allows us to exchange and modify that library without going through the whole rails app calling it. Like you could replace a HTTP library with one that speaks HTTPS without any change for the caller.
as I said with other things, it’s not a question IF we will change it, but really WHO, WHAT, HOW and WHEN…
I also think that it’s important to make a distinction between the federation protocol and the API. In my mind, everything the user thinks of as the diaspora social network (profiles, messages, activity streams, etc…) would all be generic “services” and/or “applications” implemented on top of the federation protocol. A pod could decide not to implement additional services on top of the core functionality, and third party services could decide to authenticate their service using other pods, and layer their particular service on top of their pod’s services (imagine, say, an MMORPG that you could log into using any Diaspora account from any pod, and, I don’t know, post screenshots to your activity stream, or send messages to your friends from within the game). As such, the suggestions in this proposal really would have to do with the API/service and not the federation protocol.
Versioning with interoperability table of the protocol could be a goal if I think about what to change
Hi everyone,
I’m not a coder and so I can’t comment on this proposal.
However, I noticed that people who vote “abstain” actually may mean “block.” If you look on the abstain hover it says, “I’m happy with what the group decides without me.”
If you vote “abstain” it means that you are happy with what the up/down vote is. Which means little old me could vote yes and this would pass. 
Is it possible to change your vote? I’d think it must be.
I agree with Jonne. This proposal is too vague. Maybe try to establish a set of design goals for federation?
“This proposal is too vague.” -
Yes and here I sidenote: Somehow voting on developer proposals is suited for abstract topics and general roadmap and directions. But there needs to be a structured set of documents which are referenced from such a proposal. Alternatives and how they belong to each other. Might be a wiki page citing some issues.
“This proposal is too vague”
I’m currently working on an idea but it is totally different of what Diaspora actually is, so I think it is not the time right now to propose it.Have to make a prototype first 