@julian not sure which language this is, but isn't there any sort of short-circuiting on `if`?

`if condition1 && condition2` should immediately stop if condition1 is false, leaving condition2 never evaluated

@julian @silverpill the third point which is more contentious:

- deleting a context implies all objects included in it are now orphans and can be garbage-collected (deleted, updated, moved, whatever)

@julian @silverpill right, it's a bidirectional link that should be verified both ways ideally. so you have an object claiming to be included, but you also ideally have a reverse claim of inclusion

i think you can mostly get away with doing something like:

- if context is present and it has a canonical collection, you can browse it directly. ignore the original object
- if someone declares your context and you become aware of it somehow, you can optionally add it to the canonical collection

@silverpill @julian @pfefferle @jesseplusplus @harmonicarichard the context SHOULD be copied if you want to participate in the same context, but the owner MAY Add whatever they want to an arbitrary Collection

context-unaware impls aren't prevented from participating but this will lead to a degraded experience if you're not careful. likely you would start with some graph source, filter for context, then optionally crawl replies for anything missing or otherwise optionally reverse query inReplyTo

@julian @pfefferle @jesseplusplus i've got some prior fep work on OrderedCollection.orderType and SortedCollection.sortedBy|sortOrder (1985, 1863 but not submitted yet)

but there are deeper issues when trying to do anything with Collections other than just read them as-is... i've filed several issues on w3c/activitypub etc but tldr idk what the best solution is here. the existing abstraction of as2 collections falls short when you are trying to represent data structures other than a basic set.

@julian @pfefferle @jesseplusplus but you should be able to handle an object where inReplyTo doesn't fully dereference (yet or ever). it shouldn't break processing

@julian @pfefferle @jesseplusplus shouldn't the order basically be "whatever the owner gives you"? i can see there being a SHOULD on forward-chron maybe but it's also possible for reverse chron, order of acknowledgement, or anything else. by default Adding to a collection might append a thing to either end of it. probably the simplest thing is the latest inserted item becomes the first, and the previous list becomes the rest. Reordering of collections, sorting of collections, etc is not possible

@silverpill @julian Yes, you've said as much in those discussions, but everything you've said depends on this idea of an "actor" that isn't coherent. On one hand, you seem to be arguing that outbox+inbox is all you need to duck-type an actor, but then you don't actually do anything with this concept of an actor except saying that "it can perform activities". So an actor is the range of the `actor` property? Okay, so what? No behaviors depend on this. It is a tautological definition.

@silverpill @julian how is "the entire network built around the idea"? why do you have this idea of an actor that necessarily maps to a user?

from https://www.w3.org/TR/activitypub/#actors we see that:

> ActivityPub does not dictate a specific relationship between "users" and Actors

so why introduce the concept of "observers" and then prevent users from knowing what they are following? Why the avoidance of calling a conversation a Conversation, and why the artificial limitation of not being able to follow one?