--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87r1odgqvk.fsf%40dustycloud.org.
I don't see the connection. CRDTs are about data; ocaps are about permissions.
On Sat, Nov 28, 2020 at 2:05 PM Alan Karp <alan...@gmail.com> wrote:I don't see the connection. CRDTs are about data; ocaps are about permissions.A tricky problem is how to reconcile the two.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHOTMVJ8dTsv0K3ZhHaB5u50QoAxDcg_9Bo_yDPbrj%2BcHtMa7w%40mail.gmail.com.
While the encryption you describe is interesting, I think it's orthogonal to the CRDT/ocap discussion. That is unless I'm missing something.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAFwScO-S%3DoMMmqPXmtHWN6NwuVidjV%2BWGmY8pu9p%3DLi8g5Oc4g%40mail.gmail.com.
Is there anything about a CRDT system that significantly
differentiates its data from the data held in any other mutable
resource?
the Matrix.org chat room system promises negotiated resolution of
message presence and ordering, that makes it a CRDT right?
Thanks! To argue Karp's position here, have you not left out the "and
waits for success" from the EZPZ " a holder of a writecap updates a
single symlink-like pointer to a readcap which represents the current
state of a file," and is not that elided step equivalent to waiting
for the convergence to complete, whatever that means in the CRDT
implementation?
There's no waiting required with CRDTs: you can make updates locally, and gossip them as connectivity permits. Convergence is never guaranteed to complete either (hence "eventual consistency"), and most CRDT systems are designed with the notion that peers interested in syncing the state may drop off never to return.
On 28 Nov 2020, at 20:37, Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:
A thing I don't see much attention to in ocap land as much but I do see
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87r1odgqvk.fsf%40dustycloud.org.
Most? You mean some exist that defy reality?
Fiddlesticks! the final hop is a gatekeeper that rejects messages it's
seen before, and all messages have
(source,timestamp,counter,entropy,signature) data in them, or similar,
to guarantee uniqueness.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/38ED3FF5-0FED-43B8-8948-6113AB358B41%40forgerock.com.
- How do you represent "dots" in a way that's unforgeable? (one option which is applicable to e.g. BLS signatures is to associate each dot with a public/private keypair)- How do you confer "dot generator" authority as a capability? This would seem to require a capability which designates some sort of address for the dot generator as well as the range of dots they're authorized to generate.- How are "writecaps" represented, i.e. what authorizes a peer in the system to ask a dot generator for dots and then use them to update a particular CRDT?
One question you left off is what is the root of authority? Presumably, that's the someone who starts the CRDT service. I think the answers to your last two questions come from that observation.
On Wed, Dec 2, 2020 at 10:41 AM 'Ben Laurie' via cap-talk <cap-...@googlegroups.com> wrote:Most? You mean some exist that defy reality?I might describe them as "naively designed" or "possessing bad tradeoffs".There are several cases where it'd be nice to perform a coordinated/synchronous operation among the set of peers exchanging CRDTs. The main one is garbage collection: since δ-CRDTs change state by adding "dots", they grow unboundedly. If all peers could be online and agree to perform such an operation, it'd be nice to periodically garbage collect the "dots", which would more or less involve everyone agreeing to abandon an original CRDT and move on to a new one which begins with some agreed upon state, but this is fraught with difficulty for various reasons. Using a sort of "epoch" mechanism which combines a traditional BFT consensus mechanism (requiring 2/3rds honest participants) and placing some sort of timeout on each epoch is a heavy-handed approach to this.
--Revocation is another case where such a synchronous mechanism would be desirable.Op-based CRDTs are another example of brittle CRDTs: earlier "mostawesomedude" mentioned that CRDTs are idempotent, but that isn't always the case. Op-based CRDTs require "exactly once" delivery, which is a nearly impossible guarantee to provide.Tony Arcieri
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHOTMVJkE1cF2js1o7VF%3DSYDc76hWC8NM6cmLqinAjk3Zd7Gog%40mail.gmail.com.
On 2 Dec 2020, at 21:22, Mark S. Miller <ma...@agoric.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD7Cgt3C3TQ8xUKQOE%3Dgx7ohTN5MVZn9yOH9eaMV%3DgU2uQ%40mail.gmail.com.
Ocaps can be about data too, but aren't necessarily (the line is less
squishy around E, squishier around certificate ocaps and ocap logic
databases, I'd think). Here is another way to put it: ocaps aren't just
about authority, but about behavior. Data can flow out of an object as
one type of behavior of invoking that reference.
But you're asking what the connection is, and I'm admitting straight
out: I don't know. I suspect there's something here to investigate, but
I haven't quite sussed out what it is.
The origin of this is more or less people 'splain'ing to me that I made
major errors in my systems by not putting CRDTs at the heart. As an
example, multiple people have told me "ActivityPub is hopeless because
you didn't start out with CRDTs". When trying to get clarity as to why
I feel like the responses are vague. But they might be somewhat on to,
and off of, something...
I think this is one of those cases that I'll call, at the moment,
"approach enthusiasm". You can say I'm an "approach enthusiast" of
ocaps, lisps, reproducible software. Sometimes when I see a problem, I
might grumble and indicate that I think one of the above would have
solved the problem much better. But sometimes when I make that claim, I
don't fully know... it's a gut feeling from having seen similar problems
which have been solved by these approaches, and having seen the pitfalls
from having chosen alternatives. But it may be while making a claim
that I haven't actually thought through all of the ways they would have.
None of the above are "magic pixie dust", and I know that, but it's
tempting enough to treat them way in shorthands, because I believe they
are "the right approach"... even if the ways in which they solve
problems might take longer for me to suss out (or maybe they don't in
this case!).
Similarly, I think maybe that it's that I'm encountering "CRDT approach
enthusiasts", who have seen a lot of problems successfully solved with
CRDTs, and thus they assume that the ones I'm working on would benefit
as well. I think part of this is that CRDTs have captured the
enterprise-worker-distributed-systems-mindset... the kinds of problems
facing "enterprise software" (intentionally vague there) might actually
well be suited by CRDTs generally.
I'm not quite sure where I'm going with this, and sorry if it's just too
vague. Just trying to figure out what the source of this zeitgeist is
and if I'm wrong for not giving it enough time and attention.
To give the benefit of doubt, here are maybe a few places where I think
CRDTs might compose nicely with ocap systems I'm working on:
- A cooperative quorum of vats which all want to choose the same input
and are willing to rewind as necessary to get there. Kind of like an
ocap version of (my understanding of) Distributed TeaTime.
- Similarly, setting up something like an unum system but where the
source of update-truth may actually come from multiple sources at
multiple times. Eventually, everyone's "unum presence" should
converge on the same value, having seen all inputs.
What it seems like CRDTs don't solve:
- Blockchain-type needs, such as the double spending problem, on their
own... consensus still seems necessary in the case that two mutually
opposing choices of "spending" might occur with effects (I have
enough money to buy a new computer or to buy groceries, but not
both...)
- CRDTs don't, on their own, really have anything to do with authority,
as Alan indicates. I think that is a useful observation and is
partly why I'm confused by advocates maybe indicating it'll "solve
all my problems"... a lot of my problems are authority-oriented...
- Sometimes I want opaque objects which spit out data. I don't know
how to do this other than "distributed actors with opaque machines
on the network" type approach. CRDTs don't do anything here.
Dunno. Guess that's not so helpful. Thinking out loud though. Sorry
if it sounded like I was asking a specific question when I was really
trying to figure out what's under all this murk.
Alan Karp writes:
> I don't see the connection. CRDTs are about data; ocaps are about
> permissions. Would you be asking this question if the topic was databases
> instead of CRDTs?
>
> On Sat, Nov 28, 2020 at 12:37 PM Christopher Lemmer Webber <