Base replication stop on group tangle

[Powersource]

patch for #15

[mixmix]

This language is pretty dense.
Is SXc = the sequence of c in epoch X? The maximum replicated sequence in of c in that group?

I think what you're saying is "the last message replicated of c should be the last message that references them". If this is the case it feels right in that a person is excluded when we all stop talking to them

🔥 the major problem here is that currently our message ids do not include a feedId ...so this wont work

RECOMMEND we close this and go for the crude solution for now (state the seq)

[Powersource]

This language is pretty dense.

Yeah I don't mind rephrasings, I just wanted to get the logic written down.

SXc is the maximum pointed to sequence of c's feed.

the major problem here is that currently our message ids do not include a feedId ...so this wont work

Hmm ok yeah that's a bit inconvenient now that I think about it. That's a general problem we should solve probably.

RECOMMEND we close this and go for the crude solution for now (state the seq)

Ok maybe a compromise could be to go with the sequence solution, but still keeping tangles in the messages. That way the end-of-replication is just convention that we can change in the future without breaking backwards compatibility?

[mixmix]

yeah we're not talking about dropping tangles, it's more that tangles should be redefined ... but maybe not now...
So if I understand you're saying

1. lets define exclusion with feedId + seq e.g. like

{
  type: 'group/exclude',
  exclude: [ { feedId, seq } ],
  recps: [groupId]
} 

2. lets keep tangles.group

And for this PR that means
3. we close this PR?

Would be nice to leave a TECHNICAL_DEBT.md or something ... like things we wanted to do, but might do in future/ in future iterations.... my experience with this is it is VERY expensive to spin up all the context to understand all the nuances that went into a decision

[Powersource]

my experience with this is it is VERY expensive to spin up all the context to understand all the nuances that went into a decision

Do you mean so expensive that having TECHNICAL_DEBT.md is not worth it, or that it's worth it because of that?

[mixmix]

I am suggesting we close this PR, and open a new PR with NOTES.md or TECHNICAL_DEBT.md which records this context, so that future people coming back can go "oh that's why this was this way, good to know we now have stuff in line that we could implement it how they wanted to, and the only reason they didn't was because time + existing system"
or "oh this is why we can't easily improve it, they thought of this and I can see why they paused that direction of work"

[staltz]

I am suggesting we close this PR, and open a new PR with NOTES.md or TECHNICAL_DEBT.md which records this context, so that future people coming back can go "oh that's why this was this way, good to know we now have stuff in line that we could implement it how they wanted to, and the only reason they didn't was because time + existing system" or "oh this is why we can't easily improve it, they thought of this and I can see why they paused that direction of work"

Yes, and I would recommend putting it all in the same markdown, not a separate file. Because separate files tend to gradually stay behind when the main file is updated.

It could be in some extra section, like Appendix or something. In this case maybe it should be "Additional considerations" or "Implementation considerations" or "Replication considerations".

[Powersource]

Ok