We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.
We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.
Am 09.03.2014 15:25, schrieb Paul Frazee: <metatalk>I originally intended to reply to Paul's posting in private mail, just accidentally hit the wrong button. By now I could imagine that other members of the list might actually like to follow or at least know that they don't miss a related discussion. So I keep posting via the list. Those who are annoyed: please let us know.</metatalk> > Yes, they are similar. To answer, I'll first mention that two additional posts were uploaded that explain more of the architecture: > > "In-Application Sandboxing with Web Workers" http://pfraze.github.io/2014/03/08/in-application-sandboxing-with-web-workers.html > "Communicating with Web Workers using HTTP" http://pfraze.github.io/2014/03/08/communicating-with-web-workers-using-http.html Thanks for these. It still looks related. Though I feel I'm missing something basic. Like a super-simplified paragraph of the over-all idea. > Askemos appears to solve trust in distributed application-state, correct? I'll need to read more deeply. I'm not a native English speaker. Notably here I'm inclined to say "yes", but then in turn I might have gotten your sentence the wrong way around. I rather explain: Assumptions: A) There is no trust in any remote machine and at most temporary trust in local machines. (If self-owned and self-administrated - however eventually left to the users judgment.) B) From (A) we conclude: there is no trust in any (remote) servers state. Goal: trustworthy applications, hence some application state we can reasonably assume/agree to be correct. Method: stolen from (modeled after) the legal system: don't aim for absolute truth. Rely on judgment and witness. So Askemos is somewhat like the web with the servers removed. (And not restricted to Web, though that's the easiest model to explain it). Instead of those servers, caches cooperate. A group of "cache" nodes execute what traditional web apps do at the server. However updates are coordinated among those nodes assigned to the app: they are only executed if the majority of assigned nodes agrees. That is all those nodes always audit each other. In this setting we are no longer forced to trust any single machine or operator. Malicious or not: malfunction is spotted and handled (ignored). (At least while there are less than 1/3 bad nodes.) Hence I'm inclined to say "Askemos solves trust BY distributing application state". Especially by distributing it to parties having a stake in either a) correct results b) conflicting interests iff they where trying to play foul. In an ideal world, we would integrate some Askemos-compliant cache code right into the users browser. In practice we run a process for the user close to the browser, typically at the same machine. Autonomy in this case mean: applications are autonomous from any party's dissenting interest. (Only majority dissent will stop them.) Since we guarantee (by a simple, yet clever rule how permissions might be assigned) that no person can impersonate any other, > The trust question I'm investigating is application-integrity during third-party extension. Autonomy means, in this case, freedom to introduce new software without the host's blessing, like how an OS protects its kernel so that 3rd party code can execute without auditing by the OS vendor. Like an OS, the effectiveness will then rely on a well-designed permissions model. I see. This is basically the same question we had to solve when looking into "how do those nodes run application code?". Askemos - being only the protocol level - just goes so far to say: (a) an app might have local state, the implementation is responsible to apply updates requested by the application (after having run the agreement protocol) and (b) no app shall be able modify other app's state or even it's own state bypassing the agreement step. Insofar your sandboxing text reads very related to our implementation. Obviously. Ah, yeah: applications in Askemos can communicate with each other. By passing asynchronous messages. The implementation makes sure that in - case the group of nodes maintaining the receiving application is not the same as the group of the sending app - messages are transparently forwarded to all nodes commissioned to run the receiving app. > Regarding shared state, the client/server model is continued, and so server nodes still maintain state authority, but the user may change which servers are used. Hm. This seems like "almost identical". Correct? Except that I've got the impression that your "server switch" would wholesale switch from one server to another. While Askemos lets you add/remove peers from the list supporting any particular application. So there would be a special case in Askemos, which would match your model: having an application running at peer X initially, then add peer Y and then drop peer X. Thus effectively always have only one peer run the app at the same time, though a different one after the move. Correct? (BTW: that special case is really not how you would like to run our apps in general. Instead you would normally have at least four [better seven to ten] peers assigned to run an app.) > Likewise, the permission model is still origin-based, but it treats all components of the app (page, remote hosts, worker plugins) as part of the network, and so origin is more granular. I see. That's about the point where app development became kinda confusing in our context. After all the server is virtually there even though physically not. (Another - related - confusion might be interesting to readers looking at it from a legal background: in such a network new objects are created at all nodes running the creating application at the same time and independently. Hence there is no such relationship like original vs. copy of the object. That's interesting to look at when it comes to copyright. After all the all-so-crucial act of copying never happened, still there are multiple copies...) > Servers may apply clustering algorithms to share state authority, and so (I suspect) Askemos' protocols should be applicable to them. Servers remain a network primitive for more complex topologies. Looks still more interesting. > Another notable aspect of trust is data-containment, which Workers solve by executing in the user's environment, with all APIs removed but for postMessage (no xhr). Exactly the same with Askemos. > This excites me for applications like Mint.com, which really needs proper isolation to function ethically. Great! I did not know about mint.com However a) this functioning ethically is exactly why we did Askemos in the first place b) What I'm seeing in the first five minutes from the mint.com web pages, that's about an application as we had it in mind when we started. So maybe our experiences (and code?) might be for you. Where is the users data kept in the case of mint.com? At (one or more of) the users computer(s) or at mint.com's machines? > I'm having trouble loading some of Askemos' docs, Please send details to me off-list. I'll shall investigate. Right now let me tell you: there are some old docs still linked, which we would like to drop since we broke the underlying implementation during development harming some objects to the extend that we can't modify them anymore. Dev time... Furthermore we're running the askemos.org and other web sites from our own software and test network. That is we actually test that we can run it from cheap peers behind consumer grade ADSL lines at home. Most nodes are plug computers, some are behind apache-vhosts we don't control directly. At least those tonido-plugs have a bug which requires them to be rebooted to be fixed. Etc. etc. so we know: at any time there might be nodes registered with the DNS, which are not functioning anymore. Depending on you clinet (browser) this might be a problem. Best /Jörg > but I look forward to digging in a bit. Ping me in #stackvm on freenode (pfraze) sometime. > > Be well, > Paul F > >> On Mar 9, 2014, at 4:40 AM, "Jörg F. Wittenberger" <Joerg.Wittenberger@softeyes.net> wrote: >> >> Am 08.03.2014 23:01, schrieb Paul Frazee: >>> Wrote a post summarizing an interface model I've been researching for >>> the past two years. In the scheme of redecentralizing, it's part of an >>> architecture which supports social extension of web applications in >>> order to provide autonomy from hosting organizations. >> That "autonomy" piece caught my interest. After all, it's what >> askemos.org is about. >> >>> If anybody has questions on the approach, feel free to ask; I'll post >>> a few more articles in the near future. >>> >>> http://pfraze.github.io/2014/03/08/applying-user-agent-behaviors.html >> After reading I can see that this is pretty much in line with the model >> proposed under the name Askemos. From a practical point of view it also >> looks much like the way we program our agents. >> >> However I'm left with one question: how does this relates to autonomy >> from hosting organizations? >> >> Towards this end we require active replication of the "server" end, such >> that any peer may fail (with malice) any time harming at most itself. >> >> Best >> >> /Jörg