gmane.comp.lang.e.general

v8ken: orthogonally persistent JavaScript

Tom Van Cutsem — 2013-03-29T17:00:49

Hi,

As some of you may know, my student Gillis has been working for some
time on v8-ken, which integrates the CKen [1] library with the v8
Javascript engine. The result is an orthogonally-persistent Javascript
engine. This is a key piece of the larger Dr. SES [3] puzzle.

I thought I'd send an update of how this work is progressing.

A couple of weeks ago, Gillis managed to overcome a few critical bugs
that now allow us to successfully restore a JS session from a heap
state file. I wouldn't use v8-ken for anything serious at this point,
but this is a huge milestone: it's now possible to crash a v8ken
process and restart it without loss of either local data, or messages
in-flight.

v8ken's messaging system is based on that of Ken (reliable,
FIFO-ordered messages carried over UDP). The message-passing interface
is fairly primitive at this point: simple unidirectional send and
receive of JSON-serialized messages, directed to vat IDs. No E-style
far references or promises, although that can probably all be layered
on top in JavaScript itself.

Our long-term goal is to integrate v8ken with node.js, so that we can
have an orthogonally persistent HTTP server. We don't have node.js
integration yet, but v8ken currently does have ad-hoc support for
serving HTTP requests. Consider a v8ken process started with the
following script:

var counter = 0;

var handleRequest = function(request, response) {
  if (request.uri === "/counter") {
    response.statusCode = 200;
    response.status = "OK";
    response.data = "Counter: " + (counter++);
  }
};

Visiting http://127.0.0.1:8000/counter reveals the counter's value. If
the v8ken server crashes and restarts, the counter will retain its
state.

v8ken currently runs on 64-bit Linux. The adventurous might want to
try it out for themselves!

Cheers,
Tom

[1] v8-ken: https://github.com/supergillis/v8-ken
[2] CKen: http://ai.eecs.umich.edu/~tpkelly/Ken/
[3] Dr. SES: https://es-lab.googlecode.com/files/distr-erights-in-js.pdf

Pessimistic STM

Sandro Magi — 2013-02-19T06:24:41

This paper may interest those who follow E and other event loop systems. 
Some recent results in the STM world indicate that single-threaded 
pessimistic STM is competitive with optimistic STMs due to the lower 
incidence of aborts and reduced thread sync required:

http://transact2012.cse.lehigh.edu/papers/matveev.pdf

Event loops are similarly single threaded due to the possibility of 
writes. A language that tracks side-effects could implement an E-style 
event loop and execute all enqueued read-only messages in parallel.

Sandro

Catalog of ERights project services and dependencies

Kevin Reid — 2012-11-25T19:04:30

I have sketched out a wiki page with information about centralized services that are part of the ERights project. The goal is to document who can be contacted about a service being down, and to provide an overview of our current robustness and possible desirable migrations.

current bogus url: http://wiki.erights.org/mediawiki/index.php/Services
broken proper url: http://wiki.erights.org/wiki/Services

If you have any additional information, please post it to the wiki (if you don't have a wiki account I can make one for you), or reply to this message.

Wiki URL configuration

Kevin Reid — 2012-11-25T18:41:04

This is your irregularly-scheduled reminder that wiki.erights.org needs its pretty-URL configuration done.

cap-talk

Rob Meijer — 2012-11-09T06:39:29

I know its off-topic, but given that many people are on both this and the
cap-talk mailing-list, maybe someone here knows.

Has the cap-talk mailinglist been discontinued?

“Verb tuples” for properties, faceting, and namespacing methods

Kevin Reid — 2012-11-03T22:53:36

Properties: the motivating use case
-----------------------------------

There are a number of uses for having “properties” in a language. By properties, I mean that an object's interface presents explicitly named references to other objects, which may be able to be replaced or otherwise operated on. Some other languages have idioms for defining properties, (Java)
  class Foo {
    String getBar() { ... }
    void setBar(String s) { ... }
  }
and some provide properties as a fundamental element, even giving them priority, including Python and (JavaScript)
  var foo = {
    bar: "initial value"
  };

Properties can be seen as in opposition to object-oriented programming, because they encourage the view of an object as state without behavior, as being not an active participant in the system. However, object-orientedness is not all there is to be had, and here are some use cases for properties which I see as relevant:

* Record types. The difference between a map and a record is that a
  record's interface is optimized for a static set of keys. Properties
  mean that records do not have to generate an arbitrary pattern of 
  boilerplate methods, nor do they have to use a "get(key)" interface
  which would be a pain to reimplement if you want more than a record.
  [This is a bit poorly-argued, sorry.]

* Algebraic data types are an elegant way of expressing certain data
  structures. Even if one dislikes generic data structures as API, they
  can be very useful as a foundation for implementing algorithms.
  Algebraic data types are essentially a group of record types, and
  record types essentially are nothing but properties.

* Interop with any language having properties. Notably, in JavaScript
  and Python it is ambiguous whether something is a property-per-se or
  a method.

* Highly configurable things, such as GUI widgets, often simply have
  many individually-variable attributes. (Arguably this should be solved
  in more elegant ways (e.g. a style system), but shouldn't we keep the
  simplest-thing-that-works option pretty?)


The Status Quo
--------------

E has had properties as an experimental feature for a while.

The surface syntax was originally "obj.prop", in the days when calls were written with a space instead of a dot. Later, it was changed to "obj::prop".

The original implementation was that

  obj::prop

expands to

  obj.__getPropertySlot("prop").get()

and similarly for assignment. The concept was that an object could override __getPropertySlot in order to return custom slot objects; the Miranda (default) implementation was

  to __getPropertySlot(propName) {
    def fragment := uppercaseFirstLetter(propName)
    return def slot {
      to get() { return E.call(self, "get" + fragment, []) }
      to put(v) { return E.call(self, "set" + fragment, [v]) }
    }
  }

The problem with this design is that it does not compose neatly with inheritance-by-delegation; an inheriting object's Miranda __getPropertySlot does not know whether it should invoke the super __getPropertySlot (thus getting only super's properties and not self's) or perform the generic slot construction (thus hiding a custom property defined by super).

In practice, this was always used in the default form, using getFoo and setFoo methods. This means that the flexibility of custom slots is not available.


Revisiting Properties
---------------------

As suggested above, I would like to include properties in my largely-hypothetical E redesign -- but in a way which does not increase the complexity of the language or inter-object semantics solely for this purpose. Here are some “rejected” ideas -- rejected in that they are not the one I'm talking about here:

* Just use getFoo/setFoo.
This has several disadvantages; as a naming convention, it is not very sharply distinct from "normal methods", and it means a case transformation -- dynamic property access is necessarily a matter of string-munging. If an object has a slot, say, and wishes to export it as a property, it has to include several stereotyped methods.

* A property is a verb which happens to return a slot.
This means that the implementation of an object has to define a slot -- which, for efficiency and stable identity, must be defined *outside the object expression*, that is,

  def prop {
    to get ...
    to put ...
  }
  def obj { 
    to prop() { return prop }
  }

This is a lot of extra code, and there is no way to define sugar for it which meets E's constraints on sugar. Furthermore, it means that an object has facets, possibly many incidental facets, which makes it harder to use trivial revoking/filtering wrappers, since they have to define wrappers for the facets.

* A property is a thing that is not expressed as methods.
Not in the every-interaction-is-a-message spirit of E.


The Crazy Idea: Verb Tuples
---------------------------

As you may know, a message in current E consists of:
    verb :String, args :List[any]
There are other contexts in which the notion of message may include the recipient, or a resolver for capturing the return value, but in this case we are interested in that which an object receives in a matcher and dispatches on.

I propose changing this to:
    verb :List[String], args :List[any]

Note that the verb is still just Data; it has gained only a little additional structure.

Everywhere the verb would have been some String s, we use [s] instead, so normal methods and calls are largely unchanged. Then, we can define a property as a group of methods; in particular, our "prop" example uses the verbs ["prop", "get"] and ["prop", "put"].

Why in that order? Because then we can generate slot facets by a sort of partial application, which I'm going to call "slicing" for the moment: given an object with the above methods, we derive one which has the methods ["get"] and ["put"] -- which is the slot protocol!

Since this mechanism is generic, it can be used for other “inlined” facets which impose no additional cost until they are requested as separate objects.

It interacts nicely with caretakers and other forms of wrapper, because the facets are derived by the client and so do not need to be implemented by the wrapper, nor does a non-transitive caretaker “fail insecure” by not wrapping a returned facet.

It can be used for, for example, Miranda methods in place of the "__" prefix.

Putting Verb Tuples to Work
---------------------------

Currently, a function, i.e. something invoked with the syntax obj() rather than obj.met(), is an object which has the verb "run". (This is purely a convention supported by syntactic sugar.) In the verb tuple world, suppose we use, not ["run"], but []. This maps naturally to the omitting-the-verb syntax.

Furthermore, it means that the tuple-slicing subsumes the “verb-curry” feature of current E, which is where (obj.met) generates a facet such that (obj.met)() = obj.met(). Since the actual verb is ["met"], slicing it produces the verb []. We now have invented a syntax for tuple verbs: the elements are separated with dots.

All nice and elegant, eh? Not quite. What happens if we apply this syntax to the original problem, namely properties?

If the object has a property "prop", then we now have the syntax obj.prop yielding, not the property's value, but the property slot! If you want to access the property, you have to write obj.prop.get(), or using the subscript sugar, obj.prop[].

We could reintroduce the dereference operator and write *obj.prop, or a postfix Pascal-style obj.prop^.

Or how about an alternate dot? 
obj..prop
obj::prop
obj~prop 
obj->prop
(That last one fits into certain traditions, but doesn't really have the same semantics, and in E we use arrows for asynchronous operations.)

So, that's one open problem in this scheme.


More problems
-------------

* We're defining an object by embedding its definition inside an object. Well, an object has one other set of properties than just the methods it has: its auditors. How do we define *what auditors the derived facet should have*? We could define a generic set that are applied if possible, e.g. the facet is DeepFrozen if its container is. We could let the auditors decide what they want to do for each possible facet, but on the other hand the object might want to make that decision.

* We have introduced an extra way to define facets, unlike normal distinct objects which may or may not happen to be implemented in the same place. (They are interconvertible, in that a preexisting object can be "embedded" by forwarding messages using matchers, but that's more cruft.)

This last one is the most significant argument I currently see against the inclusion of this feature.

Wiki URLs

Kevin Reid — 2012-10-28T22:05:56

This is your irregularly-scheduled nag mail. How's setting up the pretty MediaWiki URLs on wiki.erights.org coming?

I notice that /wiki/* is redirecting to Main_Page, not even the specific page URL, so all external "deep" links to the wiki are currently broken, which is bad.

Fwd: < at >RISK: The Consensus Security Vulnerability Alert:Vol. 12, Num. 41

Bill Frantz — 2012-10-12T16:14:28

But the following is an example of a concern with any runtime environment.

====== Forwarded Message ======
Date: 10/11/12 12:53 PM
Received: 10/11/12 8:53 AM -0400
From: ConsensusSecurityVulnerabilityAlert-3yDb4q2fBZk< at >public.gmane.org (The SANS Institute)
To: frantz-gNnuX2t9IJCEogu45VfRew< at >public.gmane.org

ID: : CVE-2012-0507
Title:  Oracle Java SE Remote Java Runtime Environment Code Execution Vulnerability
Vendor: Oracle
Description: Unspecified vulnerability in the Java Runtime Environment
(JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Update 30
and earlier, and 5.0 Update 33 and earlier allows remote attackers to
affect confidentiality, integrity, and availability via unknown vectors
related to Concurrency.
CVSS v2 Base Score: 10.0 (AV:N/AC:L/Au:N/C:C/I:C/A:C)
====== End Forwarded Message ======

-------------------------------------------------------------------------
Bill Frantz        | The first thing you need when  | Periwinkle
(408)356-8506      | using a perimeter defense is a | 16345 Englewood Ave
www.pwpconsult.com | perimeter.                     | Los Gatos, CA 95032

wiki DNS updated

Kevin Reid — 2012-10-11T14:37:03

I just noticed wiki.erights.org has updated. Next step is for you to adjust the Apache/MediaWiki config for nice wiki URLs, yes?

How's the wiki restoration coming?

Kevin Reid — 2012-10-07T15:47:49

How's the wiki restoration coming?

Idle musings on doing E over again

Kevin Reid — 2012-09-28T14:41:54

I was trying to get to sleep last night, and was struck by the thought of: If we were designing E from scratch (with the same goals), what would I actually do differently?

This is the list I repeatedly got out of bed to write, over a couple hours. It has at least two items which contradict each other. It probably has some items which are really bad ideas. It does not attempt any sort of consistent level of importance of its items. But I thought it might be mildly interesting.

Am I thinking of actually doing this, you ask? Well, at the moment it seems rather impractical with my available free time and to-dos. Inventing a new language is not inherently a good thing, *unless* it turned out that, for example, all current E code could be semi-automatically rewritten into the new language, thus reusing all that historical effort. On the other hand, I suspect that E *could* be more useful to the world right now if it weren't hampered by certain design choices.

(I'd be sticking this on the wiki if it weren't down at the moment...) (Sending to friam on the off chance it's an interesting topic.)

------------------------------------------------------------------------

Guidance
--------

• Early, build an implementation targeting JavaScript/SES, because what kind of modern language doesn't run "on the web"? However, allow only membraned interop with JavaScript code, because the alternative is to discard sameness.

• Aim for facilitating less-heavyweight implementations; fast interpreters, straightforwardly powerful compilers, small runtimes. (I have no idea how to put this in concrete terms to evaluate a design.)

• Start writing code with decent error handling from the start -- Make sure that every common error at all levels of abstraction produces nice results at the REPL as well as nice caller code. Use the feedback from this to get our error-propagation and error-value semantics right.

Call semantics (apply)
----------------------

• Coherent capability-styled error-propagation semantics. (The current problem is that post-sealed-throw, the natural synchronous error handling is ejectors and the natural asynchronous error handling is returning a broken reference, but there is no automatic conversion to be had. Perhaps sealed-throw was my mistake.)

• Errors are a sort of return value, broken references, but they're a sort of return value you can't incidentally-discard. Think of them like Maybe; the default action on a call is to match Just _.
If you want to pass on brokenness to your caller, you can explicitly choose to 'box a call' which is like a try{}; this gives you success-containing-failure (i.e. a slot containing a broken reference?)
TODO: Figure out whether this ruins the property that you can pass around a promise that may or may not have resolved to a broken reference.
(Perhaps the answer is that these failures are *not* broken references; they're one bit different from broken references. Boxing a call gets you a broken reference instead. You can also 'yield a call' which is explicitly passing on the broken reference you might receive. Hooray, we've invented too many kinds of calls!)

• Going the other direction, trying to have the ejector semantics in eventual programming: have a special argument-placeholder which means "The smash facet of the resolver for the innermost enclosing eventual send". (The eventual send syntactic sugar can set up a shadowing binding.)

• Consider defining errors to cause state rollback as well as nonlocal exit.

• Problem with E inheritance design: it's conflated with matchers, so type mirandas (respondsTo/getAllegedType) have the funny behavior of invoking the matcher.

• Think harder about how/if we want to provide property-access patterns; can we cooperate with methods-are-properties languages like JavaScript and Python? The original property access scheme failed because its fallback to get/set did not compose with inheritance, so it got watered down to just a getFoo/setFoo wrapper, but that is capitalization-based name mangling which is evil.

Kernel/AST/Eval
---------------

• Explicitly permit implementations to intern verbs.

• Prototype actual implementation of the ‘quasi-parser calls may be constant folded’ early.

• Keyword arguments of some sort; choose map syntax which is amenable to this or -- ooh ooh! -- build in _record objects_ to the language, which are optimized for a static set of keys.

Surface Syntax/Nonkernel AST
----------------------------

• Aim for a syntax with the elegance of Smalltalk. Try to reject keywords, or permit them only in ways which namespace them (e.g. my old idea of <keywords> like <this>).

• (Perhaps) Instead of environments which spill siblingward in the AST, provide such scoping as part of a general "omit the right bracket/flatten nesting" surface syntax. (I suspect that this doesn't actually work as it is less expressive, but it's worth testing, I think.)

• One way to test this: start with a Lisp-style surface syntax, and include a generic flattener.

• Can't be sufficient: consider objects defined within the arguments of a method call (e.g. a lexical version of the Measviz initialization).

• Build a simpler syntax, with less C-lineage-isms. Today's world is more diverse; the people who might be interested in E are less likely to be scared off by syntax. (Those who want familiar syntax can use JS/SES.) We tried tweaking our syntax towards C/Java to improve adoption and it didn't notably help.

• Syntax such that comments readily map to specific comment nodes in AST. This means that source code tools can refactor or prettyprint without losing comments.

• Make it easier to apply auditors all over the place; auditors on methods.

• Doc-comments-are-quasis from the ground up.

Naming
------

• Allow non-strings to be nouns and verbs, thus enabling
- trivial gensyms for expanded code. (Have a way to mark names as not-outside-this-scope so that we can choose to stringify them).
- avoidance of name conflicts in public "on this object" protocols.
• Idea: nominal-typed-interface objects which automatically provide name symbols.
interface foo { method x() } def object implements foo { method foo.x() {...} }
- Private protocols, as in the JS private name proposal — if we can make "not proxiable" work for us.

• Review Joule's design which contained non-string verbs.
• If nouns and verbs can be selfish, then also revisit the restriction of LiteralExpr to specific objects. Let's do better than Common Lisp!

• Start with some sort of module system that has no global namespace, or at least uses URIs as its global namespace.

• Avoid introducing any "well-known environment" issues in the distributed object protocol; start testing with application-local objects from the start.

Standard Library
----------------

• Build stream types into the standard library from the start, and design the library-idioms so that streams are cheap.

• Include a parser generator (PEG?) so as to quickly build self-hosting language tools and tools for data languages (e.g. XML, JSON) and little languages (e.g. regular expressions).

• Build HTML/XML/JSON quasis from the start, because interop with the web is a good thing.

• Design a coherent standard library, with less of a mishmash of Java-inherited objects plus E objects. Make sure that all the expected facilities of a modern language's library are reasonably available. (What are good resources for that?)

• Don't include synchronous file access.

• Do include POSIX interfaces so we aren't crippled by lack of e.g.
• file permission setting
• sockets
• capable terminal I/O

• Avoid the file-URL vs file-local-pathname confusion in the current API.

• (And on that note,) Figure out whether the URI-literal scheme can be kept without the every-URI-"scheme"-is-a-lexical-variable property.

micro-virtualization

Paul E Baclace — 2012-09-22T03:37:32

Hi, everyone.  I just saw an announcement about the "micro 
virtualization" infrastructure from Bromium (founded by Simon Crosby, a 
XenSource founder).  It appears to be an effort to encapsulate processes 
in a lightweight way without using a vm for each process playpen.  An 
overview:

http://www.brianmadden.com/blogs/guestbloggers/archive/2012/09/20/guest-blog-from-simon-crosby-explaining-what-bromium-is-and-how-it-works.aspx

Their solution is focused on enterprise IT, especially Windows desktop, 
rather than security engineering of trust in general.  They announced 
vSentry general availability recently.  They might be using a "taint" model.

I recently saw a talk about spearfishing, and the latest solution from 
IT security consultants is complete stateful packet inspection, 
retention of everything, desktop logging, and massive datamining.  I 
became aware of this because I did a pitch for some big data consulting 
in this area, but I found the invasiveness of their solution alarming 
due to the hazards of centralized control and creation of new, highly 
valuable targets.  (The particular market is big banks.)  Avoiding those 
downsides supplies plenty of motivation to do something different.

I mostly work in the cloud server-side now and I think there is a big 
need for capability systems between hosts and between clouds. Even 
ignoring public cloud marketing hyperbole, there is a definite shift 
toward using VMs as the best practice for provisioning in private data 
centers now; the exception is now "bare-metal". Bromium is likely to 
change the landscape; they claim 43 large customers already.  I wonder 
how far they can go without a programming model/api?

Xanadu/E kool-aid still not worn off,

Paul

P.S.: To email me directly, see the contact info at MetaZeta.com or 
Baclace.net or use my firstname dot lastname at g mail since this msg is 
sent from an email account with very little spam protection.

Wiki contents available

James Graves — 2012-09-04T23:52:32

Hello E-Lang'ers,

I've temporarily imported the current version of the wiki contents to
the new server.  The XML import takes a looooong time, so it was
quicker to just do the current revision rather than all versions
(which would include a lot of spam too).

http://ds7.deltamobile.com/mediawiki/index.php/Main_Page

There's no pictures or picture upload, user accounts, etc. yet.  I
just wanted to put this up in case someone wanted to look up
something.

BR,

James Graves

IRC discussion of implementing a vat with distributedpublic state

Kevin Reid — 2012-06-02T01:41:46

Sending this to the list for archival/searchability. This is an discussion which occurred today on #erights <irc://chat.freenode.net/%23erights> including myself and Andrew Miller (from the Tahoe-LAFS project, I believe) on the topic of constructing an E vat out of a distributed verified data structure (the same sort of thing as Bitcoin is).

The primary problem is: how do you preserve the capability properties for sent and received messages if there is no place to put crypto secrets?

(Incidentally, #erights has been much more active (i.e. not dead) of late, due to some migration of general capability discussion from #tahoe-lafs. Join the fun!)

------------------------------------------------------------------------

[4:04pm] <amiller> ah related but not too important, one of the things that has amused me is that in #opentransactions one of the guys trying to use the opentransactions development branch
[4:04pm] <Zarutian> amiller: a bit like Nese in Deepness of the sky
[4:04pm] <amiller> is using it for this in-game currency in this massive text-based mmorpg he maintains
[4:05pm] <amiller> it's a truly epic thing, he's worked on it for over 10 years as a pencil and paper thing, he has a large following
[4:05pm] <Zarutian> amiller: ú, ya have a link to its website?
[4:05pm] <amiller> he goes off sometimes on these stories and it takes me a while to figure out if it's in the fictional universe or it's a metaphor
[4:06pm] <Zarutian> amiller: well sometimes fiction is only made to make mega metaphors and sometimes vice versa
[4:06pm] <kpreid> opentransactions is what, a framework for bitcoinish things?
[4:06pm] <amiller> ihttp://www.devtome.org/wiki/index.php?title=Galactic_Milieu
[4:07pm] <amiller> opentransactions is very peculiar
[4:07pm] <Zarutian> kpreid: iirc it is trying to implement some of Nick Szabo ideas in bitcoin-esque system afaik
[4:07pm] <amiller> first of all it includes an implementation of chaumian blinding for cash
[4:07pm] <amiller> it uses lucre, which ben laurie wrote
[4:07pm] <amiller> so it's meant to do something right off the bat that bitcoin doesnt
[4:08pm] <amiller> on the other hand, it doesn't have any distributed component, let alone a proof-of-work-based anonymous distributed component
[4:08pm] <amiller> it's based on a heritage of systems including Loom and Truledger that use digital signatures to minimize the reliance on the server that runs the thing
[4:08pm] <amiller> but it's not a complete solution, you're still very reliant on the server, for the reason that the server is able to 'counterfeit' money
[4:08pm] <amiller> basically they don't have any double-spend solution.
[4:09pm] <amiller> they're double-spend-vulnerable to the server
[4:09pm] <Zarutian> aah, I heard about those. Dismissed them out of hand due to exacly that, lack of decentralization
[4:09pm] <amiller> well, depending on whether or not bitcoin is a valid solution to distributed anonymous agreement, something like opentransactions may be the best thing
[4:09pm] <Zarutian> but as namecoin as demonstrated, it seems to be possible to transact something else but fungible coins in blockchain based systems
[4:11pm] <amiller> the basis of any system like this is a 'consensus' component
[4:11pm] <amiller> or what i called a 'notary' in my crappy tahoe-lafs post
[4:11pm] <Zarutian> amiller: consensus of the miners?
[4:11pm] <amiller> if bitcoin is possible, then you can use the proof of work lottery as the consensus component
[4:11pm] <amiller> consensus as in Byzantine consensus, but yeah
[4:12pm] <amiller> majority vote, transaction commit, w/e
[4:12pm] <amiller> if bitcoin works, then bitcoin is the first practical 'anonymous' decentralized agreement system
[4:12pm] <amiller> if it doesn't work, you can still have any of the other kinds of distributed systems
[4:12pm] <amiller> like in ben laurie's paper about bitcoin he describes that as a network of mintettes
[4:12pm] <amiller> it's just a typical distributed system, not an anonymous-public-entry one
[4:13pm] <amiller> http://www.links.org/files/decentralised-currencies.pdf
[4:13pm] <Zarutian> amiller: well, I have been musing on how to extend something like namecoin/bitcoin so one can declare new kinds of erights that can be transacted via the blockchain
[4:13pm] <amiller> so what i want to show is that because the consensus part can be factored out,
[4:13pm] <amiller> you could do anything like namecoin or erights and just swap out the agreement component
[4:14pm] <amiller> so it can run on either a cluster of mintettes, or on a blockchain/mining network
[4:15pm] <Zarutian> I thought the main idea was that everyone checked if outstanding transactions didnt conflict with the already agreed on history of transaction which is encoded in the blockchain
[4:15pm] <amiller> well the definition of 'conflict' is extensible in bitcoin
[4:15pm] <amiller> there's a little scripting language that no one knows how to use
[4:15pm] <amiller> the model that i am using for the general case of this
[4:15pm] <Zarutian> amiller: sorry, what are mintettes? mint-ettes? somethings that mint?
[4:15pm] <amiller> is that each 'transaction' has a validation function attached to it that describes its rules
[4:15pm] <amiller> and you have to query into your history database to run the validation function
[4:16pm] <amiller> Zarutian, you should look at my example https://github.com/amiller/redblackmerkle/blob/master/toycoin.py
[4:17pm] <Zarutian> amiller: well the scripting system in bitcoin is rather small and I think it was mainly to sidestep costly updates of the client software
[4:17pm] <Zarutian> (costly in "what did the devs change now? do I bother check and continue to trust them?"
[4:17pm] <Zarutian> )
[4:17pm] <amiller> well it's just nerfed
[4:17pm] <amiller> mintettes are just nodes in a typical network
[4:18pm] <amiller> in a typical distributed system, you designate your N nodes in the network
[4:18pm] <amiller> each one gets a private key, for exmple
[4:18pm] <amiller> okay let me try saying there are three orthogonal components to any system like this
[4:19pm] <Zarutian> as meredith said in that CCC talk titled "Science of insecurity" you really do not want turing completeness in your protocols or at very least very very rarely.
[4:19pm] <amiller> a) the central agreement system, is it decentralized? single server? anonymous like bitcoin?        b) is it possible to validate transactions based on public history? how easily? merkle trees are useful here.  c) what application layer is there? Is it just one rule like bitcoin, or is there a scripting language for Smart Contracts?
[4:19pm] <amiller> now for my analysis:
[4:20pm] <Zarutian> amiller: one rule like bitcoin? what is that rule?
[4:21pm] <amiller> 1) a) bitcoin is an anonymous decentralized consensus system, the only one of its kind; b) bitcoin right now it is possible to validate transactions, but only if you have a copy of the entire history. with the merkle tree thing i'm suggesting, you can validate any transaction with just the root hash;  c) it has a scripting language, but it's disabled.
[4:21pm] <amiller> right - one rule like bitcoin - if you ignore the script, which is effectively neutered, then there is only one kind of rule for bitcoin
[4:21pm] <amiller> the sum of the inputs must match the sum of the outputs, and the signature must match the public key in each of the inputs
[4:21pm] <amiller> (that's exactly what's in my toycoin example as well)
[4:22pm] <Zarutian> well I thought the sum of the inputs must be equal or greater than the sum of the outputs
[4:22pm] <amiller> hah, yeah you're right
[4:22pm] <amiller> the difference goes to the miners
[4:22pm] <Zarutian> otherwise how would fees work
[4:23pm] <Zarutian> exactly
[4:23pm] <amiller> 2) opentransactions a) has only a single server consensus sytem for now.    b) it is not possible to validate transactions, hence the double-spend problem, it's also not meant to be fully public    c) it has a full smart contracts layer
[4:24pm] <amiller> opentransactions isn't going to go full merkle tree because they'd rather have some server reliance but gain privacy
[4:24pm] <amiller> it's probably possible to get both, using homomorphic encryption, but i can't think about that too directly or i start to go nuts
[4:25pm] <amiller> i'm mostly only interested in the full public case, so that's where i basically have to diverge from opentransactions
[4:25pm] <amiller> okay so let me ask you about how to extend erights to bitcoin
[4:26pm] <amiller> the goal of course is a) fully decentralized because we use bitcoin's mining kind of thing,  b) public validation should be possible, i can explain how to do that with magic trees
[4:26pm] <amiller> c) the scripting language should be as expressive as E.
[4:27pm] <amiller> er let me just wind myself out trying to explain how i think it will work
[4:27pm] <amiller> una are basically just state machines
[4:27pm] <Zarutian> hmm.. this has given me idea. What about transactions being like capcerts, only you can refer to other capcerts by hash and then the input to each can be used by the capcert to select which output the referring one wants, among other things.
[4:28pm] <amiller> lets hash this out i think we'll get there quickly since we're on the same page mostly
[4:28pm] <amiller> but i'm not sure about the E part
[4:28pm] * Zarutian is catching up
[4:28pm] <amiller> E is a single state machine, isn't it?
[4:28pm] <amiller> do instructions get executed in a deterministic order
[4:28pm] <amiller> there's conceptually a single-threaded linearized timeline
[4:29pm] <kpreid> for any single vat, yes
[4:29pm] <amiller> different vats are under no obligation to share a linearizable timeline then
[4:29pm] <Zarutian> as I recall E has vats and those are each singly threaded event-loops that handle messages from outside
[4:29pm] <kpreid> amiller: correct
[4:29pm] <Zarutian> (the stuff that arrives via the far refs)
[4:30pm] <amiller> okay so i have no idea how to think about the multiple vat case.
[4:30pm] <amiller> but i really enjoy thinking about a decentralized implementation of a single vat
[4:30pm] <amiller> each vat stores some state and contains rules for state transitions
[4:30pm] <amiller> and the point of the distributed network is to reach an agreement on a sequential execution of transitions
[4:31pm] <amiller> it's important to look at the worst-case complexity of applying one of these transitions
[4:31pm] <Zarutian> amiller: where would the linerization of the timeline happen? in the blockchain of some bitcoin-esqu protocol or at a vat or more something like Croquet-SimplifiedTeaTime-Router?
[4:32pm] <amiller> i'm thinking blockchain, i don't know about croquet teamtime router but my guess is that is an ordinary distributed agreement protocol?
[4:32pm] <kpreid> btw, I was playing with explicitly modeling E semantics in a nondeterministic state-machine-like setting earlier this year. what I found was that it's very hairy simply because E is an imperative programming language and even simple object behaviors are tough to describe logically
[4:33pm] <amiller> okay so for bitcoin, the 'state' at any given time is the total set of unspent inputs
[4:33pm] <amiller> there are a lot of those
[4:33pm] <amiller> any transaction though only touches a small number of them
[4:33pm] <amiller> each transaction contains some number of inputs, some number of outputs; the transaction modifies the state by deleting all the inputs it spends, and inserting a new entry for each output
[4:34pm] <Zarutian> amiller: that last is basicly what many RealTimeStragedy games use and is what Croquet used. Basicly everyone sends their commands they want to affect their portion of the (game)state to a central server that does nothing but recive them, put them in some ordered sequence and broadcasts the sequence as it gets added to.
[4:34pm] <amiller> using magic merkle trees, any operation that touches M cells can be verified using O(M * log N) where N is the total number in the database
[4:34pm] <amiller> so it's linear in the number of state cells you actually read/modify
[4:34pm] <amiller> but it's subpolynomial in the total size of the state
[4:34pm] <Zarutian> unspent inputs? dontcha mean unspent outputs?
[4:34pm] <amiller> sure unspent outputs
[4:34pm] <amiller> one mans output is another mans input
[4:35pm] <amiller> okay so any instruction in E
[4:35pm] <amiller> has some stateful effect on the vat
[4:35pm] <amiller> it's hopefully deterministic
[4:36pm] <amiller> which means anyone with a replica of the state, applying the same instruction/input, will get the same updated state
[4:37pm] <kpreid> yes
[4:37pm] <amiller> is that true of implementations of E? they use like a deterministic subset of java?
[4:37pm] <Zarutian> amiller: deterministic vat where replicas get the same broadcasted inputstream, which I think you just described, is pretty much what a Croquet Island is iirc.
[4:37pm] <kpreid> implementation language is irrelevant
[4:37pm] <amiller> okay
[4:37pm] <amiller> well then look this is all it comes down to
[4:37pm] <kpreid> E does not expose visibly nondeterministic things to unprivileged code
[4:37pm] <amiller> if the state is an authenticated data structure
[4:37pm] <amiller> then it's publicly validatable
[4:38pm] <amiller> because you only have to look at each transaction as it gets broadcast
[4:38pm] <amiller> you don't need to have a full copy of the state
[4:38pm] CIA-46 left the chat room. (Read error: Operation timed out)
[4:38pm] <amiller> so for namecoin, the state is just the dns lookup table, and every transaction is some sequence of modifications to the lookup table, so it's a natural fit
[4:38pm] <amiller> for bitcoin, the state is just a set of unspent-coins, each transaction is modifications to that
[4:39pm] <amiller> you could implement any register machine this way
[4:39pm] <Zarutian> (well namecoin has unspent-coins like bitcoin plus the dns/name-value mapping stuff)
[4:40pm] <amiller> maybe it's worth describing some kind of stack language or something to show that you can compile some kind of script into a sequence of actions on an authenticated data structure
[4:40pm] <amiller> or else just work out a couple other examples
[4:40pm] <amiller> like what sort of property rights behavior would you want to specify
[4:42pm] <amiller> the components of this system again are going to be a) some network of miners or mintettes or 'notaries' that decides on a linear sequence of transactions, b) the 'public' who follows along with each transaction but only keeps root hashes around, acting as verifiers  c) the users whoever they are that make transactions
[4:43pm] <Zarutian> amiller: hmm.. iirc namecoin allows one to subdivide the namespace one has registered a TLD for as DNS and hand out control of submappings as one sees fit. So, I wonder if one can hand out transactions (possibly conflicting ones) that do nothing but bind such a name to value A for one transaction or bind value B to the name.
[4:44pm] <amiller> ah okay so let me try to describe this state machine as a general purpose cap checker
[4:44pm] <amiller> possessing a cap is always about having the matching private key to some public key
[4:44pm] <Zarutian> (similiar on how one can serialize an unpublished btc transaction into an btc uri and encode as QR code and so on)
[4:44pm] <amiller> so when you give someone a cap, you write their public key into the state somehow
[4:45pm] <amiller> ah that's cool, that breaks my model a bit
[4:45pm] <amiller> since you can designate a public key
[4:45pm] <amiller> but give someone only a particular transaction
[4:45pm] <amiller> then they don't have hte private key / original cap, but they have an attenuated cap
[4:45pm] <amiller> i don't know how to describe that generally.
[4:46pm] <amiller> but that's the sort of thing you want to do with the authenticated data structure
[4:46pm] <amiller> it's just a big access control list
[4:46pm] <Zarutian> amiller: sound similiar on what MarkM was going on in his email list series on capcerts which I tried to condense into a wiki page and give it name: (active) capcerts.
[4:46pm] * amiller looks into it
[4:46pm] <amiller> the wiki page http://wiki.erights.org/wiki/Capability-based_Active_Invocation_Certificates
[4:47pm] <Zarutian> yes,
[4:48pm] <amiller> "We are unaware of any theory of composable auditability"  i think that is a gap that is filled in by merkletreez
[4:48pm] <amiller> you're right this is exactly what i want!
[4:48pm] <Zarutian> though I was thinking about that as a way for vats to dynamicly attenuate and or construct ?control datastructures?
[4:49pm] <amiller> ah what's a good example pattern
[4:49pm] <amiller> at this point i normally start thinking about a chess game
[4:49pm] <amiller> and i'm still certain that's the right sort of way to think of it (i got the idea from a markm page) but it usually just confuses people when i try to explain it
[4:50pm] <Zarutian> lets say you want to give someone the capability of moving a pawn forward in a chess game hosted by a vat
[4:50pm] <amiller> perfect, go on
[4:50pm] <Zarutian> but you want to attenuate it so they can only do it before move nr 25 or some such
[4:52pm] <amiller> initially, 'you' have the capability of making any move?
[4:52pm] <amiller> or only the next move?
[4:52pm] <Zarutian> only that you are on a holiday where the price of Internet connection is so high or inconvient that you want to send your friend that cap via a postcard
[4:52pm] <Zarutian> amiller: I imagine that I would have a set of capabilities to instruct the pieces of my colour to do allowed moves
[4:53pm] * Zarutian coninues
[4:53pm] <Zarutian> but you are in luck as you know the public key of his vat.
[4:55pm] <Zarutian> so you make a chit which explains, in E code, what capability you are reffering to, the code that instanciates the attenuation and the public key of the friends vat and signs it with your vat private key.
[4:55pm] <Zarutian> (the vat you use to direct the moves in that chess game)
[4:55pm] <amiller> ohhhhh yeah. it's attenuation through function closures, basically
[4:56pm] <Zarutian> then your friend presents aforesaid chit to the chess game hosting vat
[4:57pm] <Zarutian> and gets that attenuated capability
[5:00pm] * warner has been thinking about this stuff a bunch recently
[5:00pm] <warner> I keep playing around with different ways of connecting the attenuating functions
[5:01pm] <warner> there's stack-based languages, schemes where you pass one function to another (and it invokes the second function with less-powerful arguments than the first one received), schemes where you run each function in an environment that was set up for it by the previous function, etc
[5:02pm] CIA-100 joined the chat room.
[5:02pm] <Zarutian> well, that is the rough idea
[5:04pm] <amiller> warner, do they all turn out to be equivalent?
[5:05pm] <warner> I think so. I think they'll have different ease-of-programming feels, though
[5:05pm] <warner> I have to actually build a couple to compare them properly, though
[5:05pm] <Zarutian> the implementation, yet to be realized, is basicly that each capcert describes the body of an unary function that only gets a enviroment which is safeEnv augmented by a unsealer for the issuer of the capcert and (lazyly initialized) registry of sealers indexed by keyid/fingerprints of other issuers.
[5:06pm] <Zarutian> and that function is given to whoever/whatever presented the capcert
[5:06pm] <amiller> back to the chess example
[5:06pm] <amiller> in a way, at the beginning, we have a pair of mutual capabilities to play any chess game
[5:07pm] <amiller> but as we make moves, we attenuate the ways of finishing the game
[5:07pm] <amiller> eventually we've played one single chess game
[5:07pm] <amiller> we could just pass signed move transactions to each other out of band and then play the whole game in one commit
[5:07pm] <Zarutian> "whittled down the possibilities" is a phrase that comes to mind
[5:07pm] <amiller> or we can play each move on the table
[5:08pm] <amiller> maybe it doesn't matter which
[5:08pm] <amiller> suppose i have the cap of playing my opening move
[5:08pm] <Zarutian> passing signed move transaction to each other is exactly how mail-chess works afaiu
[5:08pm] <amiller> but i want to partially play it
[5:08pm] <amiller> i want to commit to moving one of my panws
[5:08pm] <amiller> but i don't yet specify which - that's where my intent may be to designate someone to have that attenuated ability
[5:09pm] <amiller> but just like before i can either just give him the ability to play both steps at once, or i can do the first one
[5:09pm] <amiller> to play partial moves like that, then the state would have to include some attenuation mechanism, a transaction isn't just a chess move, but a partial chess move sometimes
[5:09pm] <amiller> the next person definitely can't move until i've played a complete move
[5:09pm] <amiller> then again maybe they can!
[5:10pm] <amiller> what if i say that i'm only going to move a pawn on my second move
[5:10pm] <amiller> can i enter that into the state before i even make my first move
[5:10pm] <Zarutian> amiller: the attenuation mechanism is what E can express iirc.
[5:11pm] <Zarutian> amiller: depends if your set of capabilties have to be renewed every move somehow or not.
[5:11pm] <amiller> can i express either case in E?
[5:11pm] <Zarutian> lesse see
[5:15pm] <Zarutian> yes, as your move-piece-capabilities could have been attenuated with caretakers beforehand and you put in an ?thunk? which gets executed on second move before you get to decide on that turn and another thunk after. The former thunk tells the caretakers of all other pieces than your pawns to not allow through messages while the latter tells those caretakers to re-enable.
[5:17pm] <Zarutian> (that depends of course that there is a mini-cron like factility that runs such thunks implemented in the chess game support code)
[5:18pm] <amiller> is there a canonical example of chess implemented in E
[5:18pm] <amiller> or something similar
[5:19pm] <amiller> where players alternately receive caps for their turns
[5:19pm] <amiller> does it really require a cron? i wouldn't think so
[5:20pm] <kpreid> amiller: there's a "racetrack" game in the EoJ dist where players submit moves for their cars, but I forget what other point it was meant to illustrate
[5:20pm] <Zarutian> or barring that mini-cron not existing you could give your opponent a capcert that does that second move attenuation, sets a flag. Then you have your capcert that reenables if that flag is set.
[5:20pm] <Zarutian> kpreid: promise pipelining, eventual send and far references iirc
[5:21pm] <amiller> is there a single essential primitive for E? like makeBrandPair?
[5:21pm] <amiller> from which you can construct all the rest of it
[5:22pm] <kpreid> no, and makeBrandPair isn't a primitive
[5:22pm] <kpreid> the core of E is lambda calculus + assignment + turns/queued messages
[5:23pm] <kpreid> well, you could build the last
[5:29pm] <amiller> hmm, so for me to attenuate my own capability, e.g. for me to commit to moving one of my pawns but saving the decision of which one for later,
[5:29pm] <amiller> i would need to interact with some agent who held a higher cap?
[5:30pm] <amiller> if all i have is a capability to move on of my pieces on this turn, there's no way i can send a message to the vat that actually attenuates my own cap by partially constraining it
[5:30pm] <dash> amiller: what do you mean by "higher"?
[5:30pm] <kpreid> "commit to" is not well-defined in E since state is private
[5:30pm] <davidsarah> arggh...
[5:31pm] <kpreid> but you are talking about a public-state vat which changes things
[5:31pm] * davidsarah really wants to participate but has to do work
[5:31pm] <kpreid> Oh, wait, it works even in a simpler model.
[5:31pm] <kpreid> Let's imagine for a moment that the game is managed by a normal E vat and I'm another E vat
[5:31pm] <davidsarah> such as a functional process model like Erlang, for example
[5:32pm] * davidsarah goes back to doing what they should be doing
[5:33pm] <kpreid> I want to commit to "move a pawn". I write a facet (i.e. a wrapper object) which passes on only "move a pawn" messages, and I *transfer that object to the public vat*. I drop my reference to my "make any move" capability.
[5:33pm] <kpreid> Hm, but if you replace CapTP with a cryptocap system my dropping the reference is unobservable.
[5:34pm] * Zarutian raises hand: how can you assure anyone that you have indeed dropped that "make any move" cap?
[5:34pm] <amiller> mm
[5:34pm] <kpreid> Well, it just needs to be a cap system which includes a "revoke this capability" operation.
[5:34pm] <amiller> quite.
[5:34pm] <kpreid> (this implies for shareability to have a "clone-wrt-revocation" operation as well ,but that's OK)
[5:34pm] <Zarutian> kpreid: pretty much all caps would be caretaken then?
[5:35pm] <kpreid> Think of it less like a caretaker and more like dropping an entry from the swiss table
[5:35pm] <Zarutian> kpreid: aah, okay.
[5:36pm] <kpreid> But anyway, the point is that I can deliver a move-restrictor *to* the public system and so make it public.
[5:36pm] <kpreid> (On the other hand, this implies I can DoS the public system.)
[5:36pm] <amiller> lets assume you can pay for your resource
[5:36pm] <amiller> if it just comes down to state
[5:36pm] <amiller> or swissnum entries
[5:36pm] * Zarutian attempts to bribe davidsarah with a bitcoin to take part for few minutes
[5:38pm] <amiller> bitcoin afterall is basically just a usage token, you have place at least one satoshi down as a rental deposit on every bitcoin output you create
[5:38pm] <amiller> so delivering a move restrictor is creating a new object in the public vat
[5:38pm] <amiller> there's a new reference added (a new swissnum?)
[5:38pm] <kpreid> yes
[5:38pm] <amiller> oh, and if the old one is revoked, then it's a replacement
[5:38pm] <Zarutian> yes, to last (if I understand where kpreid is going with this)
[5:39pm] <Zarutian> (creating new restrictor in the public vat that is)
[5:42pm] <amiller> when i actually make a complete move, i'm also creating a new object to represent my opponents next move
[5:42pm] <kpreid> well, the game managing public vat should contain the code for that
[5:43pm] <amiller> well someone initializes the game
[5:43pm] <amiller> designates the two players by their public keys
[5:50pm] <amiller> where are the public keys in E?
[5:50pm] <amiller> vats?
[5:51pm] <amiller> if alice and bob are playing chess are alice and bob each identified by their vat, that could make sense to me but i think i'm wrong
[5:51pm] <dash> only trust makes distinctions
[5:52pm] <kpreid> amiller: in standard E a vat is id'd by a public key (used to authenticate the vat when contacting it)
[5:52pm] <kpreid> + one swissnum for each persistently accessible object
[5:52pm] <warner> hm, what if you could publish a revokecap that *anyone* could exercise?
[5:53pm] <warner> something where anybody else could present it to the public system and get confirmation that it really does revoke the authority that you claimed
[5:56pm] <amiller> kpreid, so what does it mean that in your game example above, one of the players was another E vat
[5:56pm] <kpreid> not actually necessary
[5:56pm] <kpreid> just that the communication to the public vat is over something sufficiently captp-like for my model to hold
[5:57pm] <amiller> how can i delegate a cap in E publicly, by designating their public key?
[5:59pm] <kpreid> there is no "public" in E so as soon as you do that you're creating new things, so that depends on your design of extension
[5:59pm] <amiller> mm
[5:59pm] <amiller> ok then maybe that's the essential thing you need to represent bitcoin in E...
[6:01pm] <amiller> maybe you just need one requireSignature(f, pubkey) function?
[6:01pm] welterde left the chat room. (Ping timeout: 264 seconds)
[6:02pm] <amiller> that seems clumsy, since i don't know where the pubkeys come from
[6:05pm] <amiller> in tahoe-lafs, a verify cap is a public key, and the write-cap is the matching signing key
[6:05pm] <amiller> so if i designate someones pubkey to execute some function, then they _have_ that capability even if i don't communicate anything to them
[6:06pm] <kpreid> since vats are the reliance units it's entirely reasonable to add facilities by which an object can have its vat sign something (with some kind of add'l note identifying the object)
[6:06pm] <kpreid> or similar operations
[6:07pm] <amiller> ah okay so here's where the rubber hits the fan
[6:08pm] <amiller> if someone's access to a cap is constrained by public key, how do they do one of those partial execution / attenuations
[6:08pm] <amiller> then can't send the public vat a function that signs a message for them!
[6:08pm] <amiller> they can't*
[6:09pm] <kpreid> the defined-by-public-key capability would have to be *to the move-restrictor they wrote*.
[6:09pm] <amiller> right but the move restrictor would have to support further delegation
[6:09pm] <amiller> the simplest implementation of defined-by-public-key would require the actual message to be signed by the delegatee
[6:09pm] <amiller> but that's not good enough because you can't keep redelegating publicly
[6:10pm] <amiller> i mean you could wrap your private key up in a closure and send it to the public vat
[6:10pm] <kpreid> the move-restrictor holds a *local* reference to the make-a-move cap
[6:10pm] <kpreid> so there is no signing needed
[6:12pm] welterde joined the chat room.
[6:20pm] <amiller> i'm going in a bit of a loop trying to understand current E and the capcert active invocation scheme
[6:21pm] <kpreid> I can't help you there, I only know of capcert as that thing that Zarutian rambles about
[6:21pm] * kpreid is a ocap guy, not a crypto guy, and lets that statement identity get to his head too much
[6:21pm] <amiller> Use signing key pairs to represent object identity, where the (public) signature verification key designates the object and the (secret) signing key represents the permission to be the object.
[6:21pm] <amiller> Zarutian, maybe you can help me close this gap then
[6:22pm] <amiller> i understand how to do a thing in E now, but i understand how i need to introduce a public key somewhere, and capcert does that but i don't understand where the key comes in
[6:22pm] <amiller> the public key is associated with an object?
[6:23pm] <amiller> when i create an instance of a chess game, do i create two player objects, one for alice and one for bob, each identified by a public key?
[6:23pm] <amiller> their transactions are signed messages to their respective 'player' objects in the public vat
[6:25pm] <Zarutian> amiller: the public key is associated with a vat
[6:26pm] <Zarutian> (it is going to be the same one as captp uses once I figgure out how to extract/use it)
[6:27pm] <amiller> what has to change for there to be a public-vat then
[6:28pm] <Zarutian> as I understand it a vat is something that runs somewhere and not just inert data
[6:29pm] <Zarutian> what you probably want is an unum with public state.
[6:30pm] <amiller> what would capcert look like if it ran on one of those?
[6:30pm] <Zarutian> on unum or vat?
[6:30pm] <kpreid> Zarutian: we're trying to make a public unum which *implements a vat*
[6:30pm] <Zarutian> oh, I see
[6:32pm] <amiller> public keys and signatures have to be involved, they have to be threaded along with the function calls somehow, it's just not clear yet how to bind it all up
[6:33pm] <amiller> it's no good to have every message signed
[6:34pm] <amiller> because if i create a new capability and reference that someone else can invoke, and it sends a message, that message needs to carry the weight of my original signature when the cap was defined
[6:34pm] <amiller> i don't have to sign the actual message that gets sent.
[6:34pm] <amiller> that's the first major difference between what's needed here and what capcert does
[6:35pm] <Zarutian> hmm... the only way I can think of at the moment is that the unum creator includes his public key in the initialization code then sends a signed message desginating the public keys of the players.
[6:35pm] <kpreid> amiller: I think you missed my point
[6:35pm] warner left the chat room. (Quit: yay meetings)
[6:35pm] <kpreid> amiller: when I create a new capability, I give its implementation to the public vat; this means that it uses an intra-vat, not crypto, reference
[6:36pm] <kpreid> uses an intra-vat reference to the previously existing capability, I mean
[6:36pm] <Zarutian> (to anyone replicating the vat (in effect publishing the message)
[6:37pm] <Zarutian> )
[6:38pm] <Zarutian> kpreid: so each player has in the public vat an evaluator than evals any code signed by that player?
[6:39pm] <kpreid> that's just standard E mobile code, not a feature for this, but yes.
[6:39pm] <Zarutian> so, the evaluator of each player represents that player inside the public-vat unum?
[6:42pm] <amiller> messages to those evaluators must be signed then, but those are the only kind of messages that need to be signed
[6:42pm] <kpreid> the evaluator is not a special case
[6:42pm] <kpreid> it's just one of the things that you can get access to during unserialization in a vat
[6:43pm] <Zarutian> given a starting state, signed by a public-vat unum creator(s), and the history of signed messages to the evaluators (or avatar objects) inside that unum you can do this?
[6:44pm] <Zarutian> (this being what ever amiller is after)
[6:46pm] <kpreid> I'm assuming the premise that we can define a public Turing-complete system in which we can implement an evaluator, yes.
[6:46pm] <amiller> turing-complete isn't necessary if we can pick anything else
[6:47pm] <amiller> the calculus-of-inductive-constructions that Coq is based on is sub-turing
[6:47pm] <amiller> always terminates in polynomial time in the length of the code
[6:47pm] <amiller> i don't think that aspect matters really
[6:47pm] <kpreid> sure, refinements
[6:47pm] <amiller> i don't understand this history of signed messages though
[6:47pm] <amiller> messages are signed?
[6:47pm] <amiller> oh right the messages are always signed between vats
[6:48pm] <amiller> it's just they're not always thought of as a history log i suppose
[6:48pm] <kpreid> in Pluribus (standard E comm stack), connections are authenticated using a key pair, but messages on the connection are not signed
[6:48pm] <Zarutian> amiller: each message from outside the public-vat unum that are meant to change the public state rather than merely the state of your local copy is signed.
[6:48pm] <kpreid> what a public vat needs, well, you're working that out
[6:49pm] <Zarutian> (similiar how you can keep a chess board updated based on reports heard on the radio of a chess tournament)
[6:50pm] <amiller> okay i think i follow that
[6:50pm] <amiller> alright so this avatar/evaluator and vats
[6:50pm] <amiller> a public key represents an external vat, say Alice's vat
[6:50pm] <amiller> so when i create this chess game for alice and bob, do i create player objects for each of Alice and Bob? do those objects live on the public vat or on their respective vats
[6:50pm] <kpreid> I reject the avatar notion.
[6:51pm] <amiller> Alice is white, how do I say that the first move needs to come from alice
[6:51pm] <kpreid> as I said, the evaluator is just *one of the facilities available* when unserializing messages
[6:51pm] <kpreid> there are no "player objects" on the public vat
[6:51pm] <amiller> well, some facility needs to get enhanced with a public key and a signature validation.
[6:51pm] <amiller> we're just trying to figure out which one
[6:51pm] <amiller> i think only one is necessary if we pick correctly
[6:51pm] <kpreid> there is facet-for-use-by-Alice and facet-for-use-by-Bob
[6:51pm] <kpreid> these receive move messages
[6:51pm] <Zarutian> kpreid: how else are you going to keep what Alice can do seperate from what Bob or anyone can do? the public-vat unum cant hold secrets
[6:52pm] <kpreid> signatures are needed to authorize messages, yes
[6:53pm] <Zarutian> kpreid: okay you could have facets in the public-vat unum that check if the message they recived is signed by this or that key.
[6:53pm] <kpreid> no, the signatures should properly be part of the comm layer
[6:53pm] <amiller> kpreid, in your view, where do you put the public keys?
[6:53pm] <kpreid> the part which decides *that* the facet is to receive a message
[6:53pm] <kpreid> amiller: in the comm subsystem of the public vat
[6:54pm] <amiller> i mean who desginates a public key, and when?
[6:54pm] <kpreid> the comm system is the translator between the network/crypto world and the ocap world
[6:54pm] <amiller> i need to be able to do something like say here's a new capability and it requires signatures matching <pubkey>
[6:54pm] <kpreid> in an ordinary E system, you tell the comm system to publish a cap, and thus get back a cryptocap for it
[6:54pm] <kpreid> in this one, you would provide a cap and a pubkey instead
[6:54pm] <Zarutian> kpreid: so the facet is outside the public-vat unum but inside the comm system. Does the public-vat unum serialization have anyway to specify that a facet can only recive messages signed by the desgined private key?
[6:55pm] <kpreid> No, *this* comm system is part of the public-vat-which-is-an-unum
[6:55pm] <kpreid> that is, it's part of the state which is maintained/verified distributedly
[6:55pm] <Zarutian> aah, I see
[6:56pm] <Zarutian> that was what I was trying to get at
[6:57pm] <Zarutian> so the serialized depiction of a public-vat unum contains the state accessible to code inside the unum and state supporting that code and state?
[6:57pm] <kpreid> yes
[6:58pm] <Zarutian> I was confusing the picture of the pipe with the picture of the picture of the pipe, so to speak
[6:58pm] <amiller> this publish-a-cap, i don't understand
[6:58pm] <amiller> what function is that?
[6:59pm] <kpreid> it takes a local object, i.e. one that has only intra-vat references, and makes it possible to refer to it outside the vat
[6:59pm] <kpreid> by (in normal E) generating, storing, and returning a new swiss number (+ other info) for it
[7:01pm] <amiller> is that makeURI?
[7:01pm] <kpreid> I think some e programs define a utility for it called makeURI, yes, but ordinarily it's split into two pieces, called makeSturdyRef and sturdyToURI
[7:02pm] <amiller> ahhh so makeSturdyRef probably should require a public key
[7:03pm] <amiller> and it creates a new entry in our table
[7:03pm] <kpreid> yes, exactly
[7:03pm] <amiller> so we have an authenticated datastructure that holds all the sturdyrefs
[7:04pm] <amiller> okay so there is there a way to destroy a sturdyref
[7:04pm] <kpreid> yes. in a regular vat, since the corresponding structure holds the swiss numbers for all of the exported objects, it's a critical secret
[7:04pm] <kpreid> an object can be deregistered from that table at any time
[7:09pm] <amiller> okay so if i create a sturdyRef for white's first move in the chess game, then the move message itself must be signed according to that public key
[7:10pm] <amiller> on the other hand, if i create a sturdyRef for a function that returns the move cap
[7:10pm] <amiller> then i can sign a message to that function, attenuate it, then create a new sturdyref for that wrapper
[7:11pm] <kpreid> didn't follow those steps, sorry. Are you asking about setting up an attenuation of the move cap?
[7:12pm] <amiller> i want to attenuate the move cap, but also delegate it to some other public key
[7:13pm] <kpreid> ah, so you would send a message into the public vat saying makeSturdyRef(attenuator, delegateeKey)
[7:13pm] <kpreid> and the attenuator gets unserialized into the attenuation wrapper which is publicly observable
[7:14pm] <amiller> but suppose the game began with makeSturdyRef(whites_first_move, alicepubkey)
[7:14pm] <amiller> how does alice attenuate whites_first_move
[7:15pm] <kpreid> basically for these purposes you want makeSturdyRef to be available implicitly when delivering a message to whites_first_move
[7:15pm] <amiller> makeSturdyRef-with-pubkeys will only check the signature on invocations to whites_first_move?
[7:15pm] <kpreid> there is an E builtin method which is "call yourself with the provided function", which is how you bootstrap doing stuff on the target vat
[7:15pm] <kpreid> er, "call the provided function, supplying yourself"
[7:16pm] <kpreid> (the yourself arg isn't even necessary for high-level purposes)
[7:17pm] <amiller> when would the signature be verified
[7:17pm] <kpreid> The signature of what?
[7:18pm] <amiller> of the message sent to whites_first_move
[7:18pm] <kpreid> it would be verified as part of receiving the message
[7:18pm] <kpreid> this seems obvious, so I wonder if I'm missing something
[7:18pm] <kpreid> (verified by the comm system, not the whites_first_move object)
[7:19pm] <amiller> the signature needs to be validated at some point earlier than when the message is sent
[7:19pm] <amiller> for example if alice creates an attenuated version
[7:19pm] <amiller> like only_move_a_pawn(whites_first_move)
[7:19pm] <kpreid> Alice creates an attenuated version *by sending a message*.
[7:19pm] <amiller> sending a message to whites_first_move != invoking it?
[7:20pm] <kpreid> Depends on what you mean by "invoking".
[7:20pm] <kpreid> In E, everything is an object which has methods
[7:20pm] <kpreid> a function is simply the case where there is only one ordinary method
[7:21pm] <amiller> hm, okay, so lets say that whites_first_move is an object with one method 'move()'
[7:21pm] <kpreid> But it also has the Miranda methods, otherwise it's not a well-behaved object.
[7:21pm] <amiller> now if i create an attenuation, that is a new object with a method move_a_pawn()?
[7:21pm] <amiller> did that require sending a message to whites_first_move?
[7:21pm] <kpreid> Yes, or move() if you want.
[7:21pm] <kpreid> Well.
[7:22pm] <kpreid> Within the E model, if I am Alice, I am going to create an attenuating object, and then deliver it to whites_first_move over the network (which implicitly serializes and unserializes it to do that).
[7:23pm] <kpreid> It will be defined such that when I get the object back, it doesn't serialize itself again but becomes stuck on the public vat.
[7:23pm] <kpreid> (btw for info on Miranda messages see http://wiki.erights.org/wiki/Miranda_protocol)
[7:24pm] <amiller> i don't understand what you mean by 'deliver the attenuating object to whites_first_move'
[7:24pm] <kpreid> I need to have that object exist on the public vat
[7:25pm] <kpreid> that means I send a representation of it embedded in a message to that vat — that is, to an object in that vat, and whites_first_move is the object I'm going to use, since it's what the attenuator needs to have a reference to anyway.
[7:26pm] <amiller> what kind of message is it that you send to whites_first_move in the public vat?
[7:27pm] <amiller> surely not a move() message? i'm thinking of messages as 'invocations of a method'
[7:27pm] <kpreid> Yes, but of a Miranda method in this case; specifically __whenMoreResolved (the name refers to something other than what we're using it for here)
[7:44pm] <amiller> i can't figure out how to use a __whenMoreResolved, can you give an example
[7:44pm] <kpreid> ? "are we live?"
[7:44pm] <eel2> ?  "are we live?"
[7:44pm] <eel2> # value: "are we live?"
[7:44pm] <kpreid> ok...
[7:45pm] <kpreid> ? var boardState := ""
[7:45pm] <eel2> ?  var boardState := ""
[7:45pm] <eel2> # value: ""
[7:45pm] <kpreid> ? def whitesMove(move) { boardState := move }
[7:45pm] <eel2> ?  def whitesMove(move) { boardState := move }
[7:45pm] <eel2> # value: <whitesMove>
[7:45pm] <kpreid> ? whitesMove("example")
[7:45pm] <eel2> ?  whitesMove("example")
[7:45pm] <kpreid> ? boardState
[7:45pm] <eel2> ?  boardState
[7:46pm] <eel2> # value: "example"
[7:46pm] <kpreid> ? def makeAttenuator(inner) { return def attenuator(move) { inner("pawn " + move) } }
[7:46pm] <eel2> ?  def makeAttenuator(inner) { return def attenuator(move) { inner("pawn " + move) } }
[7:46pm] <eel2> # value: <makeAttenuator>
[7:47pm] <kpreid> (obviously this is all going on in one vat)
[7:47pm] <kpreid> ? def attwhite := whitesMove <- __whenMoreResolved(makeAttenuator)
[7:47pm] <eel2> ?  def attwhite := whitesMove <- __whenMoreResolved(makeAttenuator)
[7:47pm] <eel2> # value: <Promise>
[7:47pm] <kpreid> ? attwhite
[7:47pm] <eel2> ?  attwhite
[7:47pm] <kpreid> oh, right, no retval from that
[7:49pm] <kpreid> ? var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(inner) })
[7:49pm] <eel2> ?  var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(inner) })
[7:49pm] <eel2> # problem: problem: Failed: Undefined variable: inner
[7:49pm] <kpreid> ? var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[7:49pm] <eel2> ?  var attwhite := null; whitesMove <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[7:49pm] <eel2> # value: <Promise>
[7:50pm] <kpreid> ? attwhite <- ("1")
[7:50pm] <eel2> ?  attwhite <- ("1")
[7:50pm] <eel2> # value: <Promise>
[7:50pm] <kpreid> ? boardState
[7:50pm] <eel2> ?  boardState
[7:50pm] <eel2> # value: "pawn 1"
[7:50pm] <kpreid> amiller: there we go
[7:51pm] <kpreid> the fn _ {...} gets delivered over the wire, invoked on the public vat's side and constructs the attenuator there
[7:52pm] <amiller> oh wow, thank you! that makes sense
[7:52pm] <kpreid> ...I was expecting considerably more explanation to be needed. Good to hear.
[7:53pm] zooko left the chat room. (Ping timeout: 244 seconds)
[7:54pm] <amiller> so all of the messages sent to whitesmove via the sturdyref will need to be signature validated
[7:54pm] <amiller> but it's okay to send it a __whenMoreResolved message
[7:54pm] <amiller> which contains the promise for the result of the attenuation function
[7:54pm] <kpreid> yep
[7:55pm] <kpreid> er, not quite
[7:55pm] <kpreid> the __whenMoreResolved message contains a function which contains a ref back to the caller to deliver the attenuation-facet back
[7:56pm] <kpreid> (in our scenario, that ref would implicitly need to involve a public key transfer)
[7:56pm] <kpreid> but one of the key E-nesses here is that we are defining our application logic in an OO/functional fashion, without worrying about the necessary crypto operations to present the abstraction
[8:00pm] <amiller> is there a syntax sugar for __whenMoreResolved perhaps
[8:00pm] <kpreid> we've tossed around ideas but haven't nailed it down
[8:00pm] <kpreid> most likely a "where" block (by analogy with "when")
[8:01pm] <kpreid> def attwhite := where (whitesMove) -> { makeAttenuator(whitesMove) }
[8:04pm] <amiller> whitesMove is there twice, but it seems like it necessarily has to be the same in both cases?
[8:04pm] <kpreid> in this application it is, but there could be more objects involved
[8:04pm] <kpreid> the where arg chooses what object you want to be the neighbor of what you're building; the body can be whatever
[8:09pm] <amiller> ? def dummy() { }
[8:09pm] <eel2> ?  def dummy() { }
[8:09pm] <eel2> # value: <dummy>
[8:09pm] <amiller> ? var attwhite := null; dummy <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[8:09pm] <eel2> ?  var attwhite := null; dummy <- __whenMoreResolved(fn _ { attwhite := makeAttenuator(whitesMove) })
[8:09pm] <eel2> # value: <Promise>
[8:09pm] <amiller> ? attwhite <- ("1")
[8:09pm] <eel2> ?  attwhite <- ("1")
[8:10pm] <eel2> # value: <Promise>
[8:10pm] <amiller> ?boardState
[8:10pm] <eel2> ? boardState
[8:10pm] <eel2> # value: "pawn 1"
[8:10pm] <amiller> ? attwhite <- ("2")
[8:10pm] <eel2> ?  attwhite <- ("2")
[8:10pm] <eel2> # value: <Promise>
[8:10pm] <amiller> ?boardState
[8:10pm] <eel2> ? boardState
[8:10pm] <eel2> # value: "pawn 2"
[8:10pm] <kpreid> btw in a real distributed system, you couldn't do _assignment_ of a variable from another vat - I did that just as a shorthand for passing a message back
[8:10pm] <amiller> it doesn't matter what object i call __whenMoreResolved? I don't understand the 'neighbor' relationship
[8:10pm] <kpreid> by neighbor I meant "in the same vat as"
[8:11pm] <kpreid> in *this* case it doesn't matter because you're writing all of the code in the same vat
[8:11pm] <amiller> well there's going to need to be some way that __whenMoreResolved is modified to verify a signature
[8:11pm] <kpreid> NO!
[8:11pm] <amiller> mm
[8:12pm] <kpreid> __whenMoreResolved is an ordinary method. It gets ordinary messages.
[8:12pm] <kpreid> Verifying signatures on _network_ messages is the job of the comm system
[8:12pm] <kpreid> (Which does not care what application we are implementing on it at all.)
[8:13pm] <amiller> suppose i have two move objects/functions though, whitesMove and blacksMove
[8:13pm] <amiller> and we have sturdyrefs with public keys for each of those
[8:14pm] <amiller> either you will need to sign some message in order to call makeAttenuator(whitesMove)
[8:14pm] <kpreid> no, makeAttenuator is local (serialized along with the rest) code, so no crypto ops
[8:15pm] <amiller> i get that the network is going to do the crypto ops, but i can't figure out what rule it will need to know which signature to check and when
[8:16pm] <kpreid> the table of sturdyrefs (they're not really sturdyrefs any more) stores what key(s) messages to a given object should be signed with
[8:16pm] <kpreid> in fact, you could make it 1:1 - the public key signing a message _designates_ what object to deliver it to
[8:16pm] <kpreid> (*IANACryptographer)
[8:17pm] <amiller> at some point there is going to be a move() message sent to whitesMove
[8:17pm] <amiller> but it's not going to be signed with the whitesMove public key
[8:17pm] <kpreid> yes, from the attwhite object living in the public vat
[8:17pm] <kpreid> it is a local, object-reference. no crypto needed
[8:18pm] <kpreid> the fact "attwhite contains a reference to whitesMove" is part of the vat's state
[8:22pm] zooko joined the chat room.
[8:23pm] nejucomo left the chat room. (Ping timeout: 245 seconds)
[8:25pm] <amiller> okay i think what happens is that a message signature gets checked when a sturdyref gets unserialized.
[8:26pm] <kpreid> a signature gets checked _when the comm system receieves a message_ before it delivers the message to the target object.
[8:26pm] <kpreid> That is, as far as I can see, the only sensible way to do it.
[8:26pm] <amiller> the comm system needs to know which pubkey to check the signature against though
[8:26pm] <amiller> it needs to do that not based on the message recipient but on the sturdyrefs it needs to have translated
[8:27pm] <kpreid> The comm system's job is to know what objects have been granted to what pubkeys.
[8:27pm] <kpreid> Sorry, explain that last claim?
[8:27pm] <amiller> objects get sent messages, but it's sturdyrefs that are going to be associated with pubkeys
[8:28pm] <kpreid> I think we should stop using the term "sturdyref", because a sturdyref is really a crypto thing that doesn't apply to this situation.
[8:28pm] <amiller> i need some endpoint to refer to
[8:28pm] <kpreid> A sturdyref is authority-to-send; the authority-to-send in this implementation is the *signing key*.
[8:29pm] <kpreid> (plus the target public-vat to contact)
[8:29pm] <amiller> there are two endpoints, there's the event where you designate a public key and then the even when the signature is checked
[8:30pm] <amiller> so we were talking about having a modified sturdyRef or makeURI that takes a publickey as a parameter
[8:30pm] <amiller> it doesn't matter what happens with the public key just that it is designated at some point
[8:30pm] <kpreid> yes...
[8:30pm] <amiller> so the question is where the other end point goes, and what i think is that it should go in the place where the sturdyRef is translated
[8:31pm] <amiller> like when the swissnum is looked up
[8:31pm] <kpreid> there is no swissnum
[8:31pm] <kpreid> we can't have swissnums in this system, because the vat state is public
[8:33pm] <kpreid> the replacement for the swissnum in the comm system state is the public key
[8:34pm] <kpreid> the replacement for the swissnum in a sturdyref is the private key
[8:36pm] <amiller> this fn _ { attwhite := makeAttenuator(whitesMove) })  that gets serialized
[8:36pm] <amiller> it doesn't get serialized with the text whitesMove
[8:36pm] <amiller> i'd have to refer to it by a remote ref of some kind right
[8:36pm] <amiller> like its public key?
[8:36pm] <kpreid> correct, we have to construct a remote ref, so we generate a key-pair for it
[8:36pm] <amiller> okay
[8:36pm] <kpreid> oh
[8:37pm] <kpreid> the situation is asymmetric
[8:37pm] <kpreid> if it were symmetric, we would make a key-pair and transmit the *private key*
[8:37pm] <kpreid> But we don't actually want a private key there, because the public vat is public
[8:38pm] <kpreid> er, wait, I'm confused, that's a different case.
[8:38pm] <kpreid> What I just started explaining is the case for "attwhite", the local variable that needs to get modified  by code on the public vat
[8:38pm] <kpreid> (rather, &attwhite)
[8:38pm] <kpreid> But "whitesMove" is a different case - we are sending a reference to an object in the public vat, *to* the public vat.
[8:39pm] <kpreid> So, yes, there does need to be a signature verification independent of receiving a message, to be able to designate the object.
[8:40pm] <kpreid> That verification is still invoked within the comm system, specifically the unserialization subsystem.
[8:40pm] <amiller> i think it just needs to be done during the deserializing code
[8:40pm] <amiller> when the remote ref is dereferenced
[8:41pm] <kpreid> Yes...though at some stage it is recognized as not-a-remote-ref
[8:41pm] <kpreid> (but rather local)
[8:42pm] <amiller> that transition is exactly when the sig should be checked
[8:43pm] <amiller> so you sign your serialized code
[8:43pm] <kpreid> As part of signing the message it is a component of, yes.
[8:43pm] <amiller> ah, sure
[8:44pm] <amiller> okay and if you have multiple remoterefs with diferent pubkeys, you need a signature for each one
[8:44pm] <amiller> or if you only want to have a single signature you could always group them by redelegating them
[8:44pm] <amiller> this matches how bitcoin works btw
[8:44pm] <amiller> the transations are signed
[8:45pm] <amiller> multiple times, one for each input
[8:53pm] zooko left the chat room. (Read error: Connection reset by peer)
[8:56pm] zooko joined the chat room.
[8:59pm] * amiller git-clones e-on-cl and hopes for the best
[9:00pm] <amiller> are there any other rooms i can use to play with eel2
[9:00pm] <amiller> couldn't get private messages to work with him
[9:01pm] <kpreid> by design, there is no non-public access, but there is more obscure access

------------------------------------------------------------------------

Can't pass exceptions with Java 7 :java.lang.Throwable.suppressedExceptions

Thomas Leonard — 2012-05-14T14:54:56

With Java 7, Throwables can no longer be sent successfully over CapTP. The 
error is:

=== 2012-05-14T14:44:15.109Z 
(CapTPConnection.whyNoDeliverOnlyOp:CapTPConnection.java:837) WRN
captp: whyNoDeliverOnlyOp(4, run, java.lang.ClassCastException: cannot 
assign instance of org.erights.e.elib.ref.OldFarRef to field 
java.lang.Throwable.suppressedExceptions of type java.util.List in instance 
of java.lang.ClassCastException)
--vvvv--
cannot assign instance of org.erights.e.elib.ref.OldFarRef to field 
java.lang.Throwable.suppressedExceptions of type java.util.List in instance 
of java.lang.ClassCastException


java.lang.ClassCastException: cannot assign instance of 
org.erights.e.elib.ref.OldFarRef to field 
java.lang.Throwable.suppressedExceptions of type java.util.List in instance 
of java.lang.ClassCastException
         at 
java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2063)
         at 
java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1241)
         at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1970)
         at 
java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:498)
         at java.lang.Throwable.readObject(Throwable.java:913)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
         at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
         at java.lang.reflect.Method.invoke(Method.java:601)
         at 
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1004)
         at 
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1866)
         at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1347)
         at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1964)
         at 
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1888)
         at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1347)
         at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1685)
         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1341)
         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
         at net.captp.jcomm.CapTPConnection.receiveMsg(CapTPConnection.java:741)
         at 
net.captp.jcomm.CapTPConnection.processMessage(CapTPConnection.java:724)
         at 
net.vattp.data.VatTPConnection.newIncomingMsg(VatTPConnection.java:727)
         at net.vattp.data.DataPath.newIncomingMsg(DataPath.java:699)
         at net.vattp.data.DataCommThunk.run(DataCommThunk.java:207)
         at org.erights.e.elib.vat.PendingCall.innerRun(PendingCall.java:75)
         at org.erights.e.elib.vat.PendingEvent.run(PendingEvent.java:74)
         at org.erights.e.elib.vat.HeadlessRunner.run(HeadlessRunner.java:174)
         at java.lang.Thread.run(Thread.java:722)

--^^^^--

The problem seems to be the new list of "suppressed" exceptions attached to 
each Throwable:

http://docs.oracle.com/javase/7/docs/api/java/lang/Throwable.html#getSuppressed%28%29

CapTPReplacer turns this into a far ref (presumably on the assumption that 
the list may be mutable), but the Throwable created at the destination needs 
a List, not a far ref.

I assume there's some mechanism to handle things like this (since 
getStackTrace(), which also returns an array, works fine).

This hack fixes it, but I'm not sure it's right in general ("unmodifiable" 
seems to mean "read-only" rather than "const"):

(in CapTPReplacer.substitute)

if (ref.getClass().getName().equals("java.util.Collections$UnmodifiableList")) {
return null;
}

Suggestions?

wiki.erights.org hostname config is still broken

Kevin Reid — 2012-04-27T16:19:00

wiki.erights.org still thinks its canonical hostname is its IP address, which is causing it to generate inappropriate URLs and so interfering with performing authenticated actions and spidering.

Please fix. It is making the daily spam-fighting unnecessarily tedious.


If it is convenient while you're working on this, please enable the MediaWiki API, as this will assist in the upcoming specification/testing project. <http://wiki.erights.org/w/api.php> claims that it is straightforward to do so.

Review of the state of the E project from my perspective

Kevin Reid — 2012-04-11T12:38:24

People
------

(a) As far as I know, no one is currently actively working on E implementation or major public E-related projects. If I'm wrong, then please make it clear by talking about your progress on e-lang!

(b) MarkM appointed me maintainer. I have been primarily occupied with schoolwork; the miscellaneous nature thereof has tended to discourage me from working on significant projects (or so I excuse myself). I hope that this situation will change after I graduate or after I start my job, which will occur in May and July of this year, respectively; however, I cannot promise where my enthusiasm will lie. Regardless, I will take the time to *review patches* should anyone else provide them. Please do let me know if I've been neglecting such.

Plans
-----

We have several different E implementations. (This is largely my fault.) However, they feel little pressure to converge, and innovations do not tend to be replicated/backported.

Therefore, I feel that what we most need is an E specification and accompanying automated (Updoc) tests. These materials will be composed on <http://wiki.erights.org>.

However, a wiki is editable by many parties. Regarding specification text, I do not see this as a serious problem, as monitoring and reviewing changes is sufficient. The serious problem is in the tests: if the test suite is editable, and the test suite is executed by E implementations being tested, then anyone editing the wiki can cause arbitrary code execution.

Luckily, we have a solution for that; as the secure programming language, it would be pretty silly if we didn't, no? -- We don't. In the current implementation of Updoc in E-on-Java, Updoc tests run in the privileged environment (or can be run confined but have a basically useless environment; I forget which). In E-on-CL, updoc can be run confined, but then such tests cannot test I/O facilities.

This is what I see as needing to be done:

1. Implement confined Updoc in E-on-Java, so that basic (safe env) language functionality can be tested using untrusted tests.

2. Transfer as much of the already-existing tests as can run in this environment, in E-on-Java and E-on-CL, to the ERights wiki, writing accompanying specification text as interest permits.

3. Make sure that all E implementations have a facility for running against this test suite. (There is one prototype implementation which currently does this: my E-on-JavaScript.)

3a. Enable MediaWiki API on the wiki, for robust category access.

3b. Set up a service to pack the wiki tests into a single downloadable archive, so that the wiki does not need to be spidered a lot.

4. Extend the confined Updoc so that it has a *virtualized privileged environment* so that we can test more implementation functionality. For example, <file> access should be virtualized by providing a temporary subdirectory functioning as a virtual root (note, rather than implementing a mock in-memory filesystem, which would not test the real file I/O code). These changes will make E a better capability system as well as supporting testing. Some may require backwards-incompatible interface changes.

5. Finish migrating all tests to the wiki. (However, in order for all implementations to pass all tests, this would include activities such as implementing DeepFrozen in E-on-Java.)

Request for comments: Idea for DeepFrozencyclic-dependency breaking

Kevin Reid — 2012-02-21T13:20:00

I had an idea last night. (It would be better to have some code for existing ideas, but I'm short on time and enthusiasm at the moment. Bear with me a few more months...)


Let's call this tool

 willBeDeepFrozen(p :vow)

with the following properties:

 * is DeepFrozen

 * is a transparent-except-for-== forwarder around p

 * if called before p is resolved, or if p is resolved and is not
   DeepFrozen, it will become permanently "ruined" -- all calls will
   throw.

(This last property is the same thing a Proxy does if it gets an invalid resolutionSlot.)


This allows us to break cycles of DeepFrozen objects:

 def bar
 def barW := willBeDeepFrozen(bar)
 def foo as DeepFrozen {
   ... barW ...
 }
 bind bar as DeepFrozen {
   ... foo ...
 }

If the real bar is needed, then it can be obtained, without introducing any new facilities, as

 barW.__whenMoreResolved(fn x {x})


The problem this addresses is currently handled in E-on-CL by using "EventuallyDeepFrozen", a kludge which would be applied to "foo" in the above example and which consists of foo giving access to its internals to the DeepFrozen guard, so that it can check if foo is *currently* DeepFrozen. This is much less efficient on DF checks of foo, but avoids the cost of barW's forwarding inside foo's code.

Furthermore, this serves as a general solution to the problem of cyclic dependencies among emakers while keeping <import> DeepFrozen (i.e. it does not return a promise on cyclic import, as it does now): we simply provide a way to request one of these wrappers from <import>. (It would have to crash if you do a regular import.)

I think that (if this works in practice) it is a superior solution to EventuallyDeepFrozen. What do you think?


A further refinement would be to make the forwarder transparent to == (and audit checks), thus avoiding the need to unwrap it ever. However, this would mean that it becomes ruined if examined using these ordinarily-side-effect-free before its referent resolves. This seems excessively magical. Comments?

On LtU: Discussion of Erlang-like vs E-like concurrencymodel

Mark S. Miller — 2012-02-19T23:31:28

http://lambda-the-ultimate.org/node/4453

E-style vs. Erlang-style Actors

Constantine Plotnikov — 2012-02-19T14:30:58

I have written a long post on LtU discussing why I think that E-style
actors are more powerful than Erlang style actors.

http://lambda-the-ultimate.org/node/4453

Thanks,
Constantine
_______________________________________________
e-lang mailing list
e-lang-r2jiIPW7MOYEUp5O9OQuKg< at >public.gmane.org
http://www.eros-os.org/mailman/listinfo/e-lang

Invitation to connect on LinkedIn

Sean W. — 2011-11-09T02:32:48

Discussion,

I'd like to add you to my professional network on LinkedIn.

- Sean

Sean  W.
Creative Consultant at Goodship
Greater Philadelphia Area

Confirm that you know Sean  W.:
https://www.linkedin.com/e/-6q0z07-gurprrm7-3t/isd/4847542639/WKbEARhR/?hs=false&tok=1VHybXm_nUVkY1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-6q0z07-gurprrm7-3t/j3Cq0y12RLEQN3_DWG473A_m9J4lBANekbuA/goo/e-lang%40mail%2Eeros-os%2Eorg/20061/I1686200210_1/?hs=false&tok=1qt_J2dSrUVkY1

(c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.
_______________________________________________
e-lang mailing list
e-lang-r2jiIPW7MOYEUp5O9OQuKg< at >public.gmane.org
http://www.eros-os.org/mailman/listinfo/e-lang