v0.19 ensembles #1459

Merged
fare merged 143 commits from v0.19-ensemble into v0.19-staging 2026-07-22 21:48:55 +00:00
Owner
No description provided.
fare approved these changes 2026-06-14 19:05:20 +00:00
Dismissed
@ -0,0 +4,4 @@
(import ./ucan)
(export #t)
(defstruct Actor
Owner

Should that be ActorID ?
Or else, what do you call an actual actor?

Should that be ActorID ? Or else, what do you call an actual actor?
Author
Owner

renamed to Handle

renamed to Handle
vyzo marked this conversation as resolved
@ -0,0 +16,4 @@
(auth : :list) ; UCAN authorization tokens for the message
(method : :string) ; the method invoked by the message
(body : :u8vector) ; the message body
(epxire : :integer) ; expiration of the message in UNIX seconds
Owner

expire ?

expire ?
vyzo marked this conversation as resolved
@ -0,0 +28,4 @@
(group : :string) ; destination group
(method : :string) ; the method invoked by the message
(body : :u8vector) ; the message body
(epxire : :integer) ; expiration of the message in UNIX seconds
Owner

expire ?

Maybe common class BaseMessage between Message and BroadcastMessage ?

expire ? Maybe common class BaseMessage between Message and BroadcastMessage ?
Author
Owner

done

done
vyzo marked this conversation as resolved
@ -0,0 +11,4 @@
;; context for security operations
(interface (SecurityContext Closer)
;; the actor to which this security context pertains
(actor)
Owner

owner?

owner?
Author
Owner

renamed to handle

renamed to handle
vyzo marked this conversation as resolved
@ -0,0 +62,4 @@
;; actor message handling
(interface (ActorHandler Closer)
;; reveive a message
Owner

receive

receive
Author
Owner

fixed

fixed
vyzo marked this conversation as resolved
@ -0,0 +37,4 @@
(expire token.expire :- :integer))
=> VerificationResult
(if (fx= next.type DELEGATE)
(if (or (equal? next.audience issuer)
Owner

Can you refactor so the error results are right next to the error case?

Can you refactor so the error results are right next to the error case?
Author
Owner

invert the tests? ok.

invert the tests? ok.
Author
Owner

done

done
vyzo marked this conversation as resolved
@ -0,0 +47,4 @@
=> :void
(TODO save-capability-context!))
(def public-key-cache-ttl 120)
Owner

Is that an absolute constant? Based on what standard/document? If not, I don't like arbitrary numbers sprinkled around the code without even a distinctive syntactical marker (like the defconstant of Common Lisp, the *earmuffs* of special variables (more akin to Scheme parameters), the +pluses+ around constants).

Is that an absolute constant? Based on what standard/document? If not, I don't like arbitrary numbers sprinkled around the code without even a distinctive syntactical marker (like the `defconstant` of Common Lisp, the `*earmuffs*` of special variables (more akin to Scheme parameters), the `+pluses+` around constants).
Author
Owner

meant it to be 1200.

i dont think we need to earmuff this, it is fine as it is. I hate the pluses.

meant it to be 1200. i dont think we need to earmuff this, it is fine as it is. I hate the pluses.
vyzo marked this conversation as resolved
@ -0,0 +37,4 @@
((fx= code DID-KEY-ED25519)
(bytes->ed25519-public-key bytes))
(else
(raise-contract-violation did->public-key "unknwon key type" code))))
Owner

unknown

You need M-x ispell or something

unknown You need M-x ispell or something
vyzo marked this conversation as resolved
@ -0,0 +13,4 @@
(path :- :string) ; path where the context is stored
(key :- :u8vector) ; encryption key for private key material
;; data tables
(private-keys :- HashTable) ; did string -> PrivKey
Owner

comments needed. What keys are those? Those you control, I presume.

What roots? of what? Capability domains you control? You know about?

What are the input and output anchors? A brief description, please.

comments needed. What keys are those? Those you control, I presume. What roots? of what? Capability domains you control? You know about? What are the input and output anchors? A brief description, please.
Author
Owner

ok. I think i will do an implementation backed by an sqlite db, this is transient.

ok. I think i will do an implementation backed by an sqlite db, this is transient.
Author
Owner

added comments for now

added comments for now
vyzo marked this conversation as resolved
@ -0,0 +20,4 @@
(root-output-anchors :- HashTable) ; token set
(subject-input-anchors :- HashTable) ; did string -> token set
(subject-output-anchors :- HashTable) ; did string -> token set
(tokens :- HashTable) ; token set
Owner

explain that the values are the expiries.

explain that the values are the expiries.
vyzo marked this conversation as resolved
vyzo force-pushed v0.19-ensemble from e8d93c072a to f94ee59674 2026-06-18 03:12:58 +00:00 Compare
vyzo force-pushed v0.19-ensemble from 2f3a8d0bed to edcf514acc 2026-06-18 10:42:39 +00:00 Compare
otherwise CVE waiting to happen from rainbow tables
- move security-context to ucan
- current-time-seconds
vyzo force-pushed v0.19-ensemble from 8fa7d79c5c to 5f8842141f 2026-07-13 16:05:51 +00:00 Compare
vyzo force-pushed v0.19-ensemble from cc03cbe28b to 4c1bc51836 2026-07-20 15:02:13 +00:00 Compare
Owner

Remarks after consulting with the clanker:
- [ ] 1. Problem with deterministic IV from something different than what's stored on disk is that if the on-disk representation ever changes for any reason, you have to make sure you also change the IV at the same time.
- [ ] 1. We could as well implement a general purpose way to store arbitrary rows encrypted with random IV that is stored, and some kind of HMAC for AEAD while we're at it. General-purpose, reusable.
- [ ] 6. The clanker says something I don't understand about token-anchored-at?: it never returns !AnchorVerificationError's intended breadth — context.ss / cap.ss. In capability-context's verify, when a subject is supplied you check token-rooted-at? token subject, then roots, then db-get-subject-input-anchors self subject. But db-get-subject-input-anchors with a #f subject (the subject :? := #f default path) will hash-key on #f — and verify's for (anchor ...) loop is only reached when subject is truthy anyway, so a token presented with no subject that's anchored only via a root input anchor is never checked against root input anchors at all. The root-input-anchor set is loaded and cleaned up but I don't see the verify path consulting it. Either that's dead state or a missing check.
- [ ] 8. Add tests for that optimize-call change—and for all bugs you fix.
- [ ] 9. In definline, issue a meaningful syntax error in the cases that don't match well,
instead of falling through with an unhelpful error message.
- [ ] 10. Is on-close-stream guaranteed fired once and only once per stream?
- [ ] 10. timeout helper threads (stream-input-timeout etc.) are spawned via spawn/net too and use let/cc break for the closed path; confirm a thrown (non-caught-by-break) exception in a timeout thread can't wedge a stream in a state where the control thread waits forever on a completion that never posts.

Remarks after consulting with the clanker: - [ ] 1. Problem with deterministic IV from something different than what's stored on disk is that if the on-disk representation ever changes for any reason, you have to make sure you also change the IV at the same time. - [ ] 1. We could as well implement a general purpose way to store arbitrary rows encrypted with random IV that is stored, and some kind of HMAC for AEAD while we're at it. General-purpose, reusable. - [ ] 6. The clanker says something I don't understand about token-anchored-at?: it never returns !AnchorVerificationError's intended breadth — context.ss / cap.ss. In capability-context's verify, when a subject is supplied you check token-rooted-at? token subject, then roots, then db-get-subject-input-anchors self subject. But db-get-subject-input-anchors with a #f subject (the subject :? := #f default path) will hash-key on #f — and verify's for (anchor ...) loop is only reached when subject is truthy anyway, so a token presented with no subject that's anchored only via a root input anchor is never checked against root input anchors at all. The root-input-anchor set is loaded and cleaned up but I don't see the verify path consulting it. Either that's dead state or a missing check. - [ ] 8. Add tests for that optimize-call change—and for all bugs you fix. - [ ] 9. In definline, issue a meaningful syntax error in the cases that don't match well, instead of falling through with an unhelpful error message. - [ ] 10. Is on-close-stream guaranteed fired once and only once per stream? - [ ] 10. timeout helper threads (stream-input-timeout etc.) are spawned via spawn/net too and use let/cc break for the closed path; confirm a thrown (non-caught-by-break) exception in a timeout thread can't wedge a stream in a state where the control thread waits forever on a completion that never posts.
Author
Owner

11 - timeout threads: what is the clanker hallucinating? the control thread does not concern itself with timeouts, only the reader/writer touch it and it the state it concerns itself with is just not possible. clanker fail.

11 - timeout threads: what is the clanker hallucinating? the control thread does not concern itself with timeouts, only the reader/writer touch it and it the state it concerns itself with is just not possible. clanker fail.
Author
Owner

10 - yes. on-close-stream is only invoked by the control thread of the connection, and it is guaranteed to be invoked once.

10 - yes. on-close-stream is only invoked by the control thread of the connection, and it is guaranteed to be invoked once.
Author
Owner
  1. definline error message: outside the scope of this pr. maybe follow up issue, but in general we want a solution for general improvement of error messages, there is no point in monkey patching this.
9. definline error message: outside the scope of this pr. maybe follow up issue, but in general we want a solution for general improvement of error messages, there is no point in monkey patching this.
Author
Owner
  1. errr, again this is too little too late to make a dent. we need a general purpose test framework (and lots of tests) for the compiler.
8. errr, again this is too little too late to make a dent. we need a general purpose test framework (and lots of tests) for the compiler.
Author
Owner
  1. I don't understand what it says either, i will revisit that code.
6. I don't understand what it says either, i will revisit that code.
Author
Owner
  1. I am not terribly concerned about this, because the index of the key is the did and a format change will not even find it, so not something that can silently file. I will add a check that the did matches after decryption however, this is genuinely useful.

for general purpose key storage, we need a few things, including a table that schema as part of the primitive. backlog material, we are fine for now.

1. I am not terribly concerned about this, because the index of the key is the did and a format change will not even find it, so not something that can silently file. I will add a check that the did matches after decryption however, this is genuinely useful. for general purpose key storage, we need a few things, including a table that schema as part of the primitive. backlog material, we are fine for now.
Author
Owner

6 seems like complete fabrication to me, i don't see anything wrong there.

6 seems like complete fabrication to me, i don't see anything wrong there.
Author
Owner

i think it fails to understand what let/cc does.

i think it fails to understand what let/cc does.
Author
Owner

ok, i think the complaint is about using get-subject-input-anchors when subject #f. that makes sense now, i added a check for subject truthiness before checking the anchors.

ok, i think the complaint is about using get-subject-input-anchors when subject #f. that makes sense now, i added a check for subject truthiness before checking the anchors.
Author
Owner

ok, there was an issue there, just what the clanker said was mostly nonsensical. it did detect that there is an issue however, so net positive.

ok, there was an issue there, just what the clanker said was mostly nonsensical. it did detect that there is an issue however, so net positive.
sort of use it as a mac.

note: format changes do not affect correctness, as the did is
used as an index for the blob.
fare left a comment

Some clanker reviews

Some clanker reviews
@ -0,0 +38,4 @@
(using (e (new-instance !Error::t) :- !Error)
(set! e.message msg)
(set! e.irritants irritants)
(set! e.trace "?")))
Owner

Should you return e, asks Sol?

Should you return e, asks Sol?
Author
Owner

yes.

yes.
Author
Owner

fixed.

fixed.
vyzo marked this conversation as resolved
@ -0,0 +85,4 @@
(VerificationError-reason result))))
;; check expiration
(when (> token.chain.expire 0)
(unless (<= token.expire token.chain.expire)
Owner

My clanker pal Sol says the convention is that expire is inclusive to when tokens expire, so you should be using (< token.expire ...) here.

My clanker pal Sol says the convention is that expire is inclusive to when tokens expire, so you should be using (< token.expire ...) here.
Author
Owner

no, this is correct, the token can have the same expiration as the chain it doesn't have to be strictly less.

no, this is correct, the token can have the same expiration as the chain it doesn't have to be strictly less.
vyzo marked this conversation as resolved
fare approved these changes 2026-07-22 21:48:02 +00:00
fare merged commit 974a420dfd into v0.19-staging 2026-07-22 21:48:55 +00:00
fare deleted branch v0.19-ensemble 2026-07-22 21:48:56 +00:00
fare referenced this pull request from a commit 2026-07-22 21:48:56 +00:00
Sign in to join this conversation.
No description provided.