%DiKg7pb5f8nK+9UXYkh0NFycwI4311vFpl7sJQQVV0E=.sha256Here is another use-case where tangles emerge naturally in ssb: Aggregation of entities. Github has both user accounts and organization. A repository could be owned by either, and since github is centralized, there are (relatively) few problems with that. Now compare this to git-ssb. Each "user" is simply an ssb feed, and repositories are tied to one specific feed. It is not possible to have an "organization" of multiple feeds that collectively owns a repository. A lot of code relies on the total order of messages in a feed, and an "organization" does not provide such a total order. Tangles are the natural way of restoring total order.
Another, very much related problem is that of multiple accounts of the same user. A forked feed does not get replicated, so it is risky to use the same keypair from multiple devices. Instead users are encouraged to create one feed per device. same-as messages are a suggested ad-hoc way of approaching this problem, but they don't solve it on a fundamental level. Instead, each application would have to interpret these messages on its own, implement its own tiebreakers for causal ordering, and needs to deal with forks. Different applications will do these things in different ways, leading to an incoherent user experience.
Ssb as a protocol chose a design that allows very simple replication - a linked list of messages. The two (in my opinion) most fundamental problems arising from this are the inability to subscribe to parts of a feed, and the inability to aggregate feeds into higher-level, totally ordered message sequences. Both of these are actually two sides of the same coin: A partially subscribable feed could also be viewed as multiple independent message sequences that are aggregated into the larger feed.
A while ago, I mulled over ideas for (non-ssb) protocols that support this sort of feed aggregation. The fundamental problem is getting a total order, and the conclusions I arrived at mirror the tangle structure. There's a very rich design space there. For example, with feeds not necessarily tied to a keypair, anyone could take any sort of feed and aggregate them. So I could create a "git repos @Aljoscha considers interesting" feed, and build clients that let me see a summary of them. As a consequence of this, there is no central authority on the "one true way to see which feeds are authorative" in any sense. Feed aggregation would not be a containment hierarchy, you wouldn't get a tree of feeds, but a dag.
Taken to the extreme, such a protocol could allow arbitrary feed aggregation. Returning to the example of github organization: A user who is not part of an organization could simply create a new aggregate identity that includes the old organization and themselves, and could then start commiting to the repo. A more general point of view is that such a protocol has built-in support for forking any kind of stateful entities which are computed by aggregating messages. Viewed in this way, there are interesting avenues regarding CRDTs to explore.
This leads to interesting choices in tangle extension conformance rules. Whose contribution to the tangle do you accept, whose contributions do you reject? Anyone could proclaim themselves part of a git-repository owning organization and start pushing to it. A client could choose whether it considers this person to be indeed an owner of the repository, and either reconstruct it with or without those messages. There's a fun rabbit hole here about deciding whom to consider the core of an aggregated identity, and who does not belong to it. Or the protocol could instead be more restrictive, only allowing an aggregated identity to take in other identities, but not the other way around. As I said, a lot of design space.
The major selling point of this family of protocols would be the fact that applications could code against an interface that completely hides whether the identity it deals with is a "physical" identity (based on a single keypair) or an aggregated one. This would eliminate the need for same-as messages and give apps like git-ssb more power. And you'd get partial subscriptions for free (although only the person(s) creating the messages could choose the granularity of partial subscribability).
The highly subjective view of all data - deciding which identities to treat as parts of a larger one - presents some challenges, in particular it would lead to unfamiliar user interfaces. I'm personally fascinated by the possibilities of interesting stuff that could be built on this, e.g. the ability to switch between different views of reality depending on whom you trust. But this certainly won't be the protocol to overthrow facebook...
The largest drawback however is the loss of simple replication. A replication scheme purely based on "physical" identities would be rather inefficient. A very high-level aggregated identities could (transitively) consist of many physical ones. Ideally, the protocol would not get less efficient for highly aggregated identities. But the alternative would need to somehow compute which physical feeds to replicate based on some sort of efficient representation of the high-level identity. Combine this with the subjective views on whom you consider part of an identity, and you get a lot of inherent complexity. I don't think this is unsolvable, but it is far from trivial. But who knows, maybe sending bloom-filters of "physical" identity's public keys is efficient enough in practice.
Hmm, looks like I slightly digressed from the original point that tangles are a more general solution to multiple feeds per human than same-as. But I haven't written down these thoughts anywhere, and the #ssb-tangles channel is a nice excuse to do so, so I'll just leave this post as it is. Feel free to ask any questions if some of my rambling is unclear.