On 28 November 2011 22:35, Christian Ohler <[email protected]> wrote: > On Mon, Nov 28, 2011 at 12:19, Thomas Wrobel <[email protected]> wrote: >> We always were keen to keep federation though, as well as having some >> sort of fallback view for standard wave clients. (for example, a >> gadget that displays then geolocated objects on google map rather then >> the AR view on phones). Without federation we felt our idea would >> essentially be no better then what company's like Layar or Wikitude >> already offer - we wanted the ability for anyone to independently >> publish their own feeds of data without any other company being in >> control of that feed. > > That doesn't sound like it requires federation. If all you want is > publish feeds (that are owned by the publisher and read-only to > everyone else), you can get away with a much simpler solution. >
It does if you want the feeds to allow private or "selective" publishing, which we did. You cant really have an authentication system that allows only some people to see some stuff without a server that keeps track of those permissions and the IDs tied to them. If you then want anyone to be able to start a server, you need federation in order for people on one server to see (private) content from another server. All pretty much as email is really. The exception could be if the users would have the skills/knowledge to host their own code for each potential feed, or keep the application running all the time. So you would get a p2p network, or something like Opera tried with Unite. With that though offline messages would be impossible. (unless you have a exceedingly complex data sharing scheme.....I think there has been experiments with private messages over p2p, but none comes to mind at the moment. It would, in turn, rule out realtime or sycned updates though) So you pretty much go back to square one; wfp gives evereything needed, despite the downside of it being relatively speaking quite complex.
