The ampitheater pattern, and what Chip really means by the "Unum Pattern"?

[Christopher Lemmer Webber]

I'd like to talk about this underdocumented gem at some point:

http://www.erights.org/elib/distrib/unum/index.html

Maybe this Friday? I guess we'd have to see if we could get Chip on.

I have an interpretation of this. I wonder if it's true. I also wonder
if my understanding of the Unum Pattern is right, per Chip's definition.
I think I know now, even though I've clearly been wrong before.
Hopefully I'm now less-wrong. Here's my short version:

Most "distributed" conversations talk about distributed *data*, but
the Unum Pattern instead is about distributed *behavior*.

My interpretation of the Ampitheater Pattern is it's a way of scaling
the unum pattern to large interactions, more or less.

Wonder how close that is to reality?

- Chris

[Mark S. Miller]

Notice that the stage vat shows only left to right arrows. Others are bidirectional.

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/87y2bo7yxp.fsf%40dustycloud.org.

[Christopher Lemmer Webber]

Noticing it, since you point it out.

Could you expand on the significance of that? :)

My assumption is it having to do with mass-distribution of content but
I'm unsure.

[Mark S. Miller]

Y. Scanning. Multicast with no flow control. No feedback. 

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/87czsz8yu1.fsf%40dustycloud.org.

[Mark S. Miller]

On Sat, Jun 5, 2021 at 8:30 PM 'Mark S. Miller' via friam <fr...@googlegroups.com> wrote:

Y. Scanning.

Bad predictive typing. Meant "scaling".

 

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAK-_AD47szC0K8UN4D_M8Cv1PJk_ekXCg7pR0THvUdozDGfAqg%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Chip Morningstar]

On Jun 5, 2021, at 3:02 PM, Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:

I'd like to talk about this underdocumented gem at some point:

 http://www.erights.org/elib/distrib/unum/index.html

Maybe this Friday?  I guess we'd have to see if we could get Chip on.

I’d be delighted to join a conversation about unums.  This Friday would be fine.

I have an interpretation of this.  I wonder if it's true.  I also wonder
if my understanding of the Unum Pattern is right, per Chip's definition.
I think I know now, even though I've clearly been wrong before.
Hopefully I'm now less-wrong.  Here's my short version:

 Most "distributed" conversations talk about distributed *data*, but
 the Unum Pattern instead is about distributed *behavior*.

I like that.

My interpretation of the Ampitheater Pattern is it's a way of scaling
the unum pattern to large interactions, more or less.

Wonder how close that is to reality?

It was not so much about scaling the unum pattern per se but about scaling a particular use case (which was, approximately, to keep Britney Spears from melting Communities.com)

— Chip

[Christopher Lemmer Webber]

[+ Dan Finlay, see the end of the email]

Chip Morningstar writes:

>> On Jun 5, 2021, at 3:02 PM, Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:
>>
>> I'd like to talk about this underdocumented gem at some point:
>>
>> http://www.erights.org/elib/distrib/unum/index.html
>>
>> Maybe this Friday? I guess we'd have to see if we could get Chip on.
>
> I’d be delighted to join a conversation about unums. This Friday would be fine.

Great! :)

>> I have an interpretation of this. I wonder if it's true. I also wonder
>> if my understanding of the Unum Pattern is right, per Chip's definition.
>> I think I know now, even though I've clearly been wrong before.
>> Hopefully I'm now less-wrong. Here's my short version:
>>
>> Most "distributed" conversations talk about distributed *data*, but
>> the Unum Pattern instead is about distributed *behavior*.
>
> I like that.

:D

>> My interpretation of the Ampitheater Pattern is it's a way of scaling
>> the unum pattern to large interactions, more or less.
>>
>> Wonder how close that is to reality?
>
> It was not so much about scaling the unum pattern per se but about
> scaling a particular use case (which was, approximately, to keep

> Britney Spears from melting Communities.com <http://communities.com/>)
>
> — Chip

Oh well, good then... I got the use case right!

This came up because Dan was asking me about how ocap social systems can
be "scaled up". I pointed to the ampitheater pattern, but I wasn't sure
if it matched what I thought it was, but we did something similar in
ActivityPub called sharedInbox to handle a similar scenario... I think
it functioned in pretty much the same way at a high level (there were
several things done wrong about it as both written and deployed... alas,
it was done in a rush once Mastodon adopted ActivityPub to handle their
scaling needs... I didn't realize what mistakes I was making at the time
when I suggested the "solution").

The use case the ampitheater and sharedInbox both cover I think is: if
Patrick Stewart on machine A has millions of followers, and thousands of
them are on machine B, instead of sending the same message one million
times from A->B, it should be possible to have an object that is sent to
once on B that then fans out to all the relevant recipients.

Aside: one thing I like to point out (and Dan agrees) is that what a lot
of systems don't focus on is *scaling down* (anti-abuse tooling is a
great example of this, with current approaches assuming centralization).
Concerts are a communication system we experience, but more
conversations happen over the phone or around a table at a coffee shop.
We should not require Starbucks Corporation for our coffee shops to be
able to operate as social gathering spots... independently run
operations are important.

Anyway, looking forward to Friday!
- Chris

[Alan Karp]

On Sun, Jun 6, 2021 at 10:46 AM Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:

The use case the ampitheater and sharedInbox both cover I think is: if
Patrick Stewart on machine A has millions of followers, and thousands of
them are on machine B, instead of sending the same message one million
times from A->B, it should be possible to have an object that is sent to
once on B that then fans out to all the relevant recipients.

That sounds very much like the pattern we accidentally discovered in SCoopFS.  See Figure 10 of https://www.hpl.hp.com/techreports/2009/HPL-2009-53.pdf.

--------------
Alan Karp

[Mark S. Miller]

Aside: one thing I like to point out (and Dan agrees) is that what a lot
of systems don't focus on is *scaling down* (anti-abuse tooling is a
great example of this, with current approaches assuming centralization).
Concerts are a communication system we experience, but more
conversations happen over the phone or around a table at a coffee shop.
We should not require Starbucks Corporation for our coffee shops to be
able to operate as social gathering spots... independently run
operations are important.

Well put!