Hackers, I'm no expert in these matters, but I've been pondering over a few things concerning prospective GNU Social implementations. As I've seen elsewhere on this list, feel free to sort the nonsense from the legitimate concerns.
I'm very much interested in how GNU Social is effectively redefining the ideas behind how we communicate over the Internet (using essentially existing methods), and one of my biggest concerns is about centralization/distribution of the protocol. XMPP, as others have stated, a very promising way to establish presence over such a social network, and something else established on this list is the concern over domains one does *not* control (i.e. facebook.com) having a monopoly on the connectivity. Here were my thoughts on that (and please hang in there): 1. Facebook has at least one thing right: the amount of bandwidth you have to expend in order to establish sure lines of communication with your friends (though at the cost of privacy) is relatively low. Would it seem outrageous to, at first, use a single XMPP server (daisycha.in?) to establish the concept of presence for the purpose of data transfer? 2. Once the protocol and system is established, just about anybody could run their own XMPP server for presence establishment, making groups of geographically near friends' connectivity much faster, while providing a means to connect to those on separate ([email protected]) XMPP/GNUsocial servers. 3. An idea I rather like for security is modeled here, using GPG extensively for security, at the cost of a SHARP increase in bandwidth for **everyone**. (Think Freenet, only worse). I'm using this as a concrete example, something to look at; whether this is the final method (I hope not) is not my point. /******************************************/ /******************************************/ A. Alice, Bob, Carol, and David are all users of GNU Social, and are all mutual friends of each other, though on separate XMPP/presence servers. Each has a private GPG key, and each has each other's public GPG key. For the purposes of this model, they are all mutual friends on the network, but have no other mutual friends. B. Alice is the only one of these friends online. She requests David's profile. This request (request.Alice.profile.David+MessageID) is queued for delivery. C. Carol gets online, and through XMPP's presence system, Alice becomes aware of her on the other network. Alice's queued profile request is sent to Carol (since they are both friends of David). Alice goes offline. D. Bob comes online. Carol sends request.Alice.profile.David+MID to Bob. E. David comes online, with his freshly updated profile. Bob and Carol both submit request.Alice.profile.David+MID to David. David's client safely ignores the duplicate request, thanks to the MID. F. David encrypts his profile using D's private GPG and A's public GPG. Initiate send.Alice.profile.David+MID to Bob and Carol. G. Bob and Carol exchange a check.Alice.profile.David+MID, and establish that they both have send.Alice.profile.David+MID, so re-sending the data is not necessary; they both have it. H. David goes offline. Carol goes offline. Bob is still online when Alice finishes class and checks her GNU Social. Bob's client initiates a check.Alice.profile.David+MID, and verifies that Alice does not have David's profile. I. Bob (who could not read David's encrypted profile transmission) sends it on to Alice, who easily decrypts the data and enjoys reading about David's new favorite movies. MISSION ACCOMPLISHED. J. Carol and David come back online, and exchange a MID check with Alice, who affirms that she did indeed receive the encrypted profile data, and there's no need to send it again. /******************************************/ /******************************************/ 4. PROS/CONS Benefits: Profile data can have different levels of privacy for each friend, for example if David would rather Alice not be able to read about his exploits with Ellen the night before, David need not send it to Alice. Also, thanks to GPG, nobody along the "daisy"-chain is able to read the message before it arrives at its final location. Security++. The data is never sent to the servers, only between friends. Drawbacks: Too many to count. This adds extensively to the already quite extensive XMPP overhead. I was reading that some 60-70% of all XMPP traffic is overhead for presence establishment, and since XMPP data transmission without Jingle must convert binary streams to and from a base64 translation to allow it to coexist within the XML standard of XMPP. That's (excuse me) a shitload of bandwidth, once aggregated with all other traffic. Something to consider, though, is that if all of this data *is* encrypted with GPG keys, there's no reason NOT to send it to the servers (though that does increase the server load and storage dramatically). Nobody could read it there anyway (except the intended recipient). Just something that's been bugging me. I had a dream about this system, woke up, and decided to type it out. Hope I was coherent. --Andrew Gray (Sweetandy) [email protected] Happy hacking!
