Remove group tangles

[staltz]

Context

We had a video call yesterday to discuss how to proceed with #15 being stuck, and we came to a conclusion which is #34.

Problem

However, #34's exception for tangle integrity means that maintaining the integrity of the group tangle means effectively replicating all messages from the excluded member, sort of nullifying the benefits of that exception entirely.

Solution

I suggested removing group tangles because they don't seem to solve any concrete problem at hand, but instead are creating a new problem. This PR shows how that would look like.

Caveat

One of the previously claimed benefits of group tangles is that

discovering group discussions that give context to the exclusion of a given
member (and thus the creation of a new epoch).

Which this PR removes. However, I think it's fairly simple to fix this, by just having a free-form part of the exclude message where the admin can insert a "reason" field or link to a discussion thread.

Another thing removed by this PR is how the init of the next epoch is NOT directly linked to the exclude msg in the previous epoch. However, I also think we can just add that msg ID if we need to, or we can even question why do we NEED to link these in the first place. What (concrete and experienced) problem would they solve?

[mixmix]

maintaining the integrity of the group tangle means effectively replicating all messages from the excluded member, sort of nullifying the benefits of that exception entirely.

There is a risk of replicating a lot, if there are a lot of offline communication/ coordination, or the excluded people are in network islands with excludees.

On thinking about it more I'm not that worried about this case. I think what will happen is Oscar might get back from a holiday with their friend Percy, and they have been chatting, collaborating, then Percy replicates and sees Oscar is out. Their collab with Oscar will pull Oscars messages in .. but not once they're in sync.

I guess my question is "how bad could it get?" with the group tangle.
I am hesitant to change things till we need to??

Also it's easy to drop the group tangle, but impossible to put it back in eh?

[staltz]

The risk of replicating a lot is there, and we don't know yet how people (excluded people) could game this to maximize their revenge. I think the group tangle is a great way how they could game the system, and I'd like to close that door.

Again, why are we having a group tangle? What problem does it actually solve? I've been asking this almost a year now and got no answer. We should drop such "solutions".

I am hesitant to change things till we need to??

What about not adding solutions till we need them??

[Powersource]

I tried looking through the tribes2 code but couldn't find a place where the group tangle is directly used. Fwiw.

Still, I think the group tangle is nice metadata. It doesn't inherently hurt anything. The ooo replication we just decided on is a separate maybe-problem we've introduced.

What about not adding solutions till we need them??

As mix says, it's easy to take out but impossible(ish) to put back in. If people would start using groups, then 2 years later realize a group tangle would've been great for some future feature, then we can't go back and add it to all old messages.

How about here

4.8.2.C. (Out-of-order fetching for tangle integrity) As an exception to
4.8.2.B., whenever a is validating a tangle (see section 4.10) and detects a
missing message Q, they SHOULD fetch Q in out-of-order fashion (OOO, that
is, specifically requesting that message from remote peers, disregarding
the feed in which it was published), even if Q is from an excluded member. See
figure 8 as an example.

changing SHOULD to MAY. Defined as

5. MAY This word, or the adjective "OPTIONAL", mean that an item is
   truly optional. One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

Then we could leave it up to the ux designer of whatever app implements this in the end, if they want complete or incomplete history in a group. While still keeping a clear definition and ordering of everything that's canonically in the group.

[staltz]

I like the change from SHOULD to MAY, and I can see that regarding killing group tangles, I'm the minority here. But still I'd like to invite you two to think about it, not from a perspective of "nice to have" and "possibly in the future might be useful" but from good programming principles such as YAGNI (you ain't gonna need it), KISS (keep it simple), and rule of least power.

To quote a few, "Always implement things when you actually need them, never when you just foresee that you will need them" Ron Jeffries co-founder of XP and "It is hard for less experienced developers to appreciate how rarely architecting for future requirements / applications turns out net-positive" John Carmack.

On the argument of "impossible to add in the future", I think this is overstated. It's not too hard to create a new group schema with a few tweaks, possibly even automating the migration.

[Powersource]

When it comes to software I agree with KISS etc. But software has traditionally been very mutable and adaptable. We're however working with immutable data structures. That's probably more comparable to building a house that might last a 100 years, and where you can't suddenly swap out the foundations. I wonder if building architects agree with YAGNI, or if they have another principle they work by.

[mixmix]

I like the "MAY" suggestion. At this point I think we can agree it's an empirical question and we need to choose one, document this decision fork for future explorers and perhaps choose the path which would be best to illuminate.
I tend cautious on this one, and agree with Jacob this is not a programming env like those quoted were working in.

Propose we go MAY and move on

[staltz]

Ok, y'all win :)

12f9d71