Why not just say "objects that can be treated as actors need to define themselves as actors as part of their `type`.
You have an entire concept of allowing multiple types to be put into the type object. It would work well here! My Profile & Actor object!
No, instead it is "my Profile object, which might have an inbox and outbox... also a Note might have an inbox and outbox, and an Article might have an inbox and outbox..."
@hrefna oh, and we should have _definitely_ used a different word for "actor types" in AS2 (not the only types that can be `actor` in an activity, btw) and `Actor` objects in AP. It's confusing. The `actor` of an activity doesn't have to be an AP `Actor`, nor does either of them have to have an AS2 "actor type".
@hrefna the inbox! If you can send it a 'Follow' activity, it is followable. It is a feature because there are lots of followable things, which makes the world more interesting.
I'm going to flip your question: can you imagine any ways that it might be interesting to follow a Note or an Article?
What, semantically, allows me to identify an actor? If they can be things other than AP Actors or whatever, what do I use to identify the fact that I can "follow" the object? Why is it a feature that this information is not encoded into the type field?
What does it mean to follow a Note? What would I expect the behavior to be from that? How should I be expected to interact with the followed Note? What happens when a Note follows me?
Who defines and controls the Note's permission model?
@hrefna I think the point is that we can build interesting applications on top of AP. I think FEPs or other light standards can be used for creating them.
In the case of content objects as actors, best proposal I've seen is that the object shares all the activities that affect its history - creates, updates, replies, likes.
@evan It's not that I can't come up with an answer for where this would make sense, but if I say "I am submitting something to this Profile & Application" that's a very different semantic meaning than "I have identified that this random Profile in the world might be able to accept messages so I sent it a follow request."
I'm sure it can be answered all sorts of ways that this is useful, but I have trouble seeing why this can't or shouldn't be explicitly denoted when it can occur?
@hrefna so, it sounds like you think we should have used multi-typing for actors, or maybe a single Actor root class.
But we didn't. We went with duck typing instead, which seems to work fine. Either of those other ideas would have worked, but this works, too.
If you want to know if you can send an activity to an object's inbox, you check to see if it has an `inbox`. If you want to read its outbox, you check that it has an `outbox`.
@evan To start with: the only definition of the inbox I can find is in the context of AP Actors? If that's all that's required to define it, that is definitely not clear. https://www.w3.org/TR/activitypub/#inbox links to the actors section, where 4.0 says that a "Profile can be an actor" but then it goes on to define (in 4.1) actors as having far more than an inbox
But I can't really see the use without also defining a _behavior_ to go along with it, which making that clear in type would be far preferable, IMO?
@evan For instance: I can define an application specific behavior for an actor object and build that as an extension. We'll call it Auditing. Now you can follow my note and have a best-effort notification when it is destroyed or otherwise modified. Modifications end up in its inbox/outbox and you can read the history. Very nice
Then the type is [Note & Auditing] and everyone can automatically know by referencing a doc what behavior I attached to it and they know what it means to follow it.
@evan But someone else has another implementation! This one is publicly _modifiable_ in narrow ways. Let's say that people can submit _translations_ for it. That's also a cool feature!
But very, very different from Auditable.
So my type for that one is [Note & CommunityLanguageSupport].
This provides clear signal to anyone who looks at the object what's going on.
As it is, and I'll freely admit this may be a "me" issue, I have trouble with "this Note may have arbitrary actor behaviors" 2/2
@hrefna I also want to say that I am *really* appreciating your implementation notes as you are going along. It's really hard seeing you struggle, and there are some painfully valid criticisms of the architecture and approach. I hope we can make the experience better for future devs.