Redecentralize

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

Askemos appears to solve trust in distributed application-state, correct? I'll need to read more deeply.

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.

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. 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. 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.

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). This excites me for applications like Mint.com, which really needs proper isolation to function ethically.

I'm having trouble loading some of Askemos' docs, 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

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

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

Reading your response and reading Askemos' docs, I'm inclined to say our projects solve fairly different problems. Let me step through the Mint.com example to hopefully clarify the differences.

Mint's application is hosted by remote servers which proxy to your bank's host servers. The details may have changed by now but, at one point, they asked for your username and password, then crawled your bank interface with an HTML-scraper. The issue with this system is, of course, data-containment: you give up your financial information to Mint in order to power the app.

In the runtime-extension architecture I'm suggesting, the banking site (let's say Citibank) behaves like a miniature OS. When a user goes to citibank.com, they'd use an in-site UI to load Mint.com's application into a Web Worker. Now contained on the client-side, Mint would be given readonly access to the financial information, and read/write access to a section of the DOM for rendering its UI, and no other privileges. This solves the data-containment issue.

The User-Agent behaviors and HTTP messaging handle the question of IPC between the Citibank page and the Mint worker. Typed links are used to export/discover the interfaces between those two threads.

I don't attempt to solve the need to trust Citibank's remote service, but I do offer a way to extend Citibank's software at runtime without compromising its integrity. Mint, in this case, is one such extension ("now with more graphs!"). What Web applications choose to make alterable is at their discretion, but, because integrity of the host page is always preserved, and because typed links can be used to do behavior- and security-reasoning, it should be safe for users to share extensions with each other (like they share pages now). Users, therefore, have the autonomy to develop and personalize Web applications without belonging to the host organization. Following our example, you don't have to be a Citibank dev to dev Citibank.

I'd need to research it more deeply, but I suspect that Askemos' protocols could be implemented in this extensions-architecture as a set of reltypes. It might be used to cluster multiple Worker scripts and remote services which all implement the same reltypes, but which are all written by different authors, in order to compare the integrity of their output. Does that sound correct?