Stephan Lichtenauer <fbsdlists@xxxxxxxxxxxxxx> wrote: ... > I agree, that is also one of the first things that > comes to my mind: Synchronise addresses and maybe > other information like calendaring, some kind of notes, > ... (plugin architecture might make sense here) to > services like Facebook, Xing, LinkedIn, Google Calendar > and maybe even my mobile phone... I would like to see a cross-platform peer to peer network services framework that cuts these huge websites out of the loop completely, providing similar services in a completely peer to peer fashion. IMO Haiku has a unique opportunity to create a community service network, which could become a killer application. (A killer service?) Something that makes people flock to Haiku and stay with us. (The rest of this post is just my thoughts on how to approach implementing something like this. Feel free to comment/correct.) Fully peer to peer, server-less, authenticated, encrypted, open and extensible. Ideally your friends would host your (encrypted) online backups, webmail, photo albums, videos, blogs, bookmarks, run compute jobs, and provide your web services to other trusted peers when you might be offline. The core of this should be kept as simple as possible, simply allowing peers to find and trust each other. For one peer to connect to another it would need its IP-address and its public key. (Optionally its port number and maybe the protocol version.) Peers try connecting to the last known IP of their friends and authenticate on contact to see if it was the right peer. To initially invite your friends to your peer services you would create a peer file, mostly embedding your current IP and public key, and share that file with your friend by whatever channel available. (You would of course be free to publish your presence by whatever online services you like.) With some ISPs IPs change all the time, so peers would likely have to ask around among its common friends when two peers have both lost track of the other peer. I don´t know how to approach firewalled clients. A firewalled client will eventually try to connect outwards. Common friends might help alert the firewalled party. Two firewalled peers might need even more help. I don´t know how to approach a server-less scenario with two firewalled peers without any connected common friends. Peers´ upper layers, services and transportation should be able to differ wildly between peers. This should not hinder peers from a meaningful exchange of services that both peers support. A peer should be able to expose different services to each of its peers. I wouldn´t be surprised to learn that something like this has existed for years already. /Jonas.