I like this a lot and would love to attend one of the events.
I created Servant (https://www.servant.co) as different expression of these themes, with an emphasis on convenience, as well as user and developer experience.
- A Servant hosts your data separately from the apps you use in the cloud. (Centralized, but there is more to it...)
- You can connect your Servant via Oauth2 to share your data with any app.
- You pay Servant by purchasing API Requests to transmit data. Your fees are passed through Servant to the developers of the apps that put your data to use via API Tracking on Servant's end.
– Further, apps get access to users' credit card information and can charge users without needing to prompt them for payment information.
serious question: how does this work for something like Facebook? Things like Facebook and Twitter don't work well in a decentralised fashion (Does Lady Gaga need to be able to deal with 4 million concurrent connections for all her followers?).
Take email as an example, if basic mail delivery wasn't severely broken, due to dynamic ip addresses, lack of convenient encryption, spam and overall security concerns it would be extremely easy to self host everything related to email yourself, at least in principle.
Want to follow Lady GAGA? Just subscribe to a mailing list.
Some of the mechanisms of Twitter, Google Plus and Facebook can easily be mapped to an email like protocol. Friend requests correspond to whitelisting or a special filter on the mails you receive, same goes for "Circles". Hashtags would similarly correspond to potentially dynamic mailing lists, that could be hosted by basically anyone and indexed by a separate service.
To publish something on "your wall" just send an email to a mailing list you control, to make a post "private" just encrypt it using the public key of your indented recipients, etc.
The problem with todays services is that they don't rely on a publicly defined protocol and essentially dumb if somewhat elaborate implementation of that protocol, but instead offer a public "open" API to a service that is proprietary.
Also too many people are probably caught up in thinking about the web only in terms of http and neglect to think about the possibilities of services that don't fit neatly in that framework. Especially convenient save encryption is not implementable in the browser without plugins at the moment, as far as I can see.
From reading it appears that the basic concept is:
1) Web app inside user browser (unhosted app seems to be defined as an app that runs in the browser, client side)
2) Web app communicates with a 'personal server', basically a server that handles that and only that users data
3) 'personal server' is the thing that brokers connections with the outside world, but doesn't have to interact with a browser app if it isn't required to.
4) Here comes the bit that's actually hard and it gets a bit low on detail:
"There are situations where going through a third party is unavoidable, for instance if a certain guitar dealer only sells on eBay, or a certain friend of yours only posts on Facebook. For each of these "worlds", we will develop application-agnostic gateway modules that we can add to our personal server. Usually this will require having a "puppet" account in that world, which this gateway module can control. Sometimes, it is necessary to use an API key before your personal server can connect to control your "puppet", but these are usually easy to obtain. To the people in each world, your puppet will look just like any other user account in there. But the gateway module on your personal server allows unhosted web apps to control it, and to "see" what it sees.
They would work but they are more difficult to build. Unfortunately noone has an incentive to put the amount of resources towards public infrastructure that Facebook & co do, therefore it stays centralized.
They're not just more difficult to build, there are only two options in an infrastructure like those. You can build a system where everything depends on one server (where if your internet isn't good enough everything breaks) or you use a Bitcoin-esque system to make sure that every computer on the network gets the messages. Which causes noise and inefficency.
I created Servant (https://www.servant.co) as different expression of these themes, with an emphasis on convenience, as well as user and developer experience.
- A Servant hosts your data separately from the apps you use in the cloud. (Centralized, but there is more to it...)
- You can connect your Servant via Oauth2 to share your data with any app.
- The data is kept in fixed formats to promote using the same data across multiple applications – https://github.com/servant-app/json-archetypes
- You pay Servant by purchasing API Requests to transmit data. Your fees are passed through Servant to the developers of the apps that put your data to use via API Tracking on Servant's end.
– Further, apps get access to users' credit card information and can charge users without needing to prompt them for payment information.
– And much more...
My skype ID: austencollins