Absolutely, Tom. It’s a means of agreeing a plan and getting something done.
@tomscott haha, I thought it would be best way to get the ball rolling on this and since it purposes doing things a little differently than I’ve seen them done before, I wanted to make sure the community had a say in the decision. C=
I hope nobody feels left out by me starting ahead on a clean-room implementation for federation… but it really is not such a complicated or huge task for it to require elaborated documents or planning.
My plan of stuff to implement for this gem is:
-
DO NOT BUILD ON RAILS (bonus: lightning fast specs) [done]
-
get xml de/serialization on database-unrelated entities to work in both directions [done]
-
build a structure resembling what is currently known as ‘to_diaspora_xml’ [done]
-
put payload in salmon envelope and sign/encrypt that as it is currently done in D* [pending]
-
simulate sending/receiving inside a proof-of-concept test-app [pending]
@florianstaudacher Really cool stuff! Watching, will keep an eye on this. Do you think the availability of federation in a gem might, in theory, allow a developer the ability to incorporate Diaspora federation into just about any Rails app? 
@florianstaudacher Cool! Thanks for jumping on that. I don’t think planning or documentation is ever a bad thing, and it also gives an opportunity for others to learn new stuff and help out if they want, but I appreciate that you’re taking the time to get stuff done.
Fantastic work, Florian.
@seantilleycommunit in theory, yes, you could re-use the gem in other ruby projects. but keep in mind that the gem just represents the “business logic”. you’d have to handle the http routes and the database persistence in the app - that’s really out of scope for the gem.
- put payload in salmon envelope and sign/encrypt that as it is currently done in D* [done]
Started trying to put together some better documentation around this. Currently working off the articles Sean posted here and trying to make them more readable and useful. Not done by any means yet, but just a heads up on what I’m doing.
alright, the code in my github repo should now have every entity we use for federation, also the ones with nested entities inside (e.g. StatusMessage -> Photo, Location).
they can be de-/serialized from/to XML and are meant to be put in a Salmon envelope that can be de-/encrypted.
I still want to implement some rudimentary validation classes, so the received objects can be sanity-checked before they are being handled by an actual app, but apart from that I think we could start to think about how to test this on its own and with another instance of D* running the current federation code.
… it will need a lot more work before we can actually run a pod with it.
not only do we have to give it a decent test period, also a good part of the diaspora code will have to be adapted just to use the new gem.
@florianstaudacher I’ll be more than happy to help you with this. I’ll try to give a look at it this weekend, just let me know what needs to be done
Well, to anyone who would like to help, I can suggest to review my code and the docs I write with it.
I may be an intermediate-advanced programmer but that certainly doesn’t mean everything I write is pure gold. I want this to be as good as it can get, so we have a rock-solid library we can use for Diaspora* and possibly to have something other projects could use to integrate federation into their software.
Anyway, this will become the new reference implementation of our protocol, so this has to be impeccable, readable and understandable.
@florianstaudacher Would it be possible to move these updated docs into the federation section of our wiki at some point? It’d be really great to brush up what little information we have on how the protocol works, and update it with all the information you’ve put together.
Hey, without understanding the technical stuff, it seems like there’s been a lot of progress with this.
Seems to me like an agreed standard for decentralised social network federation should be a major outcome that the diaspora project should be working towards - and that this needs to be something that can be used by other social networks. I think it would be really good to work with a few other distributed social networks (movim and gnustatus come to mind as to my mind projects with potential) from an early stage to develop a protocol that can be flexibly and easily extended and some kind of process/foundation that becomes the agreed way of agreeing and improving this.
Now might be a good time to start thinking about this could be made happen? Working with groups such as the free network foundation (thefnf.org), the free software foundation, the electronic frontier foundation and others might be a way forward?
On a totally different note, any thoughts on how diaspora should deal with linking to profiles? On facebook etc. someone can give the http address to their profile which anyone can click on, look at and then press to subscribe/friend/etc. On diaspora this is more complicated if the profile is hosted on a different pod - plus being logged in or out and consistency of how sites look becomes a bit of an issue. Plugins or third party cookies might be a way of solving this but bring up obvious privacy issues… (sorry if I’ve not explained this issue very well…)