Loomio

Change the federation protocol

F Flaburgan Public Seen by 44
F

Flaburgan Sat 1 Sep 2012 10:19PM

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.

ST

Sean Tilley Sat 1 Sep 2012 10:26PM

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.

ST

Sean Tilley Sat 1 Sep 2012 10:29PM

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.

JH

Jonne Haß Sat 1 Sep 2012 10:40PM

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.

FS

Florian Staudacher Sun 2 Sep 2012 12:25AM

as I said with other things, it's not a question IF we will change it, but really WHO, WHAT, HOW and WHEN...

S

SleepyDaddySoftware Sun 2 Sep 2012 4:08AM

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.

G

groovehunter Sun 9 Sep 2012 10:51PM

Versioning with interoperability table of the protocol could be a goal if I think about what to change

T

tortoise Tue 11 Sep 2012 2:10AM

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.

JH

Jeremy Huffman Tue 11 Sep 2012 3:11PM

I agree with Jonne. This proposal is too vague. Maybe try to establish a set of design goals for federation?

G

groovehunter Tue 11 Sep 2012 7:57PM

"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.

Load More