trwnh:

Outbox is required by the spec so it’s a good idea not to leave it out.

I’m apparently not communicating clearly and I apologize for that. I’m discussing Collections with an inbox property and no outbox property. These are not AP actors and outbox is not required in this case. However, I agree the property should be (must be) present for AP actors, since that’s required by the AP Rec.

trwnh:

I think the outbox should be there even if private, and I think it should also have a followers collection even if private. I don’t think an inbox alone is “enough” to send a Follow, yeah.

Why? Technically, an inbox endpoint is enough for sending and receiving a Follow (and any other AP activity, AFAIK). I don't know what the purpose of a private outbox would be for S2S purposes (a non-private outbox could be used to back-fill content).

IIUC, you're proposing using the presence of a followers property as an object-level capability indicator. Although I haven't seen it used that way in AP implementations, it's an interesting idea.

trwnh:

bumblefudge:

I think a Collection could have an inbox, without becoming an Actor

That’s a distinction without a difference.

I'm not convinced this claim is accurate. As you know, AP inboxes are based on Linked Data Notifications (LDN) and is intended to be interoperable with it. A notification receiver in LDN has an inbox but there's no concept of an actor. One could view a Collection with an inbox and no outbox as an LDN Receiver rather than an AP Actor (assuming the Collection is not the actor in AP/AS2 activities).

----An aside...

Practically speaking, I'm wondering if the inbox URI in an AP S2S-only context is essentially an advisory for where to POST messages related to the object associated with the inbox. No inbox collection is required and, in fact, most AP S2S-only servers, like Mastodon, do not maintain an inbox collection. There's also no requirement for actor-specific inboxes in S2S (the actor inbox can refer to a server-level inbox), so it seems to me that the relationship between the two is relatively loose. However, actor-specific inboxes are useful for the rarely used C2S API where a client needs to dereference a URI to a Collection of their specific inbox activities.

silverpill:

My main point is, actors and collections are different beasts. Actors, activities and objects are representations of things that actually exist: people, their interactions, posts. Collections are more like REST API endpoints.

I don't agree with that view of Collections. A Collection can also represent something that actually exists. However, the AS2 collection paging approach does seem to be more of a presentation-oriented API than a domain abstraction, so that muddies the topic a bit.

trwnh:

It’s just architecturally cleaner to give it its own inbox property. And also a followers collection, even if it’s private, to indicate that it can be followed.

Sounds reasonable to me, but my point was that inbox property doesn’t necessarily make the object an “actor”. It could just be identifying an HTTP endpoint for sending Follow requests. Those Follow requests might be acted upon (Accepted or Rejected) by some separate actor (the attributedTo actor, a collection manager of some kind, the “instance actor”, etc.).

silverpill:

trwnh:

Can you expand on this? I don’t see a problem with followable collections, and in fact, I see several things it could solve.

ActivityStreams spec defines actors, objects, activities and collections as different core types. That follows the principle of separation of concerns, and generally a sensible thing to do, from the implementer’s perspective.

Actors perform actions, other entities are affected by those actions.

The AS2 Follow activity can be used with any Object, not just actors. AS2 says that it "Indicates that the actor is "following" the object". The means that supporting Follow doesn't require the followed object to have an outbox (primarily a C2S concept in AP) or an AP/LDN inbox. I don't see any issue with separation of concerns on this specific topic. However, I agree that treating a collection as an actor may do that. On the other hand, if the collection is logically performing actions (e.g., self-deleting references to activities after some time), then it seems reasonable to me. Just making a collection follow-capable wouldn't justify treating it as an actor.

Publishing collection changes is an interesting case. If the collection is publishing Announce activities, where it is the object of the actor property, then it does seem to at least an AS2 actor. I'd need to think more about whether it would be required to be an AP actor (with a required inbox and outbox).

The AS2 Recommendation defines actors as "entities capable of carrying out an Activity" and (for the Applicationactor property) "[describing] one or more entities that either performed or are expected to perform the activity". One can infer that any Object referenced or Link'ed to by the actor property of an Activity type is an actor that "carried out (or performed) the activity".

The ActivityPub Recommendation added additional requirements for an actor to have inbox and outbox endpoints. (However, the inverse isn't necessarily true. An object with an inbox and outbox endpoint may or may not be an AP actor.)

From my perspective this means there are AS2 actors and there are AP actors. The former have no inbox/outbox requirement. The AP actors are a constrained variant of AS2 actors. An application can have both kind of actors. Obviously, the AS2-only actors cannot communicate using AP inboxes, but they may still be useful, in general, for modeling "entities capable of carrying out an Activity".

I'm not making any claims about well this would interoperate given how the existing AP implementations have evolved. Most current applications are hard-coded to a very restricted subset of AS2 types and often make actor-related assumptions that are not part of the AS2/AP Recommendations.

In practice, beyond the 5 core actor "types" in AS2, identifying actor and extended actor types seems to me to be very application-specific.

scott:

Search engines would not see them.

This doesn't seem to be true.

The content of Julian's post at https://socialhub.activitypub.rocks/t/hi-julian-i-wonder-how-search-engines-and-seo-will/4135/12?u=stevebate is indexed with both socialhub and nodebb URLs.

Google SERP screenshot:

pfefferle1: they kind of treat a "Note" as an "Article" by showing a preview (when text is above x chars) with a "show" more link This is UI-specific, right? I use the Mastodon "advanced UI" on the desktop and there's no "show more" expander control. It only has a scroll bar for the long text. However, the Ice Cubes iOS app has a "Show full post" expander for the same post (for example).

julian: nor anyone else I know of, for that matter — treat anything that's not as:Note or as:Question specially. I don't think that's the case, but maybe you meant something more specific than what you wrote? Several implementations support content-related AS2 content types (both base types and extensions) that do not fallback to as:Note or as:Question. For example, Funkwhale has "Libraries", "Tracks", "Audio" (etc.), PeerTube has "PlayLists" and "Video", PixelFed has "Story", Mobilizon has "Event", and so on. jupiter_rowland: Same reasoning as for hard-coding the 500-character limit. Unfortunately (in my opinion), that's only hard-coded in the UIs. I often see "Note" content, from non-Mastodon servers or patched Mastodon instances, that are 1000s of characters long in my feed and the viewing UX is not very good.

Hi @devnull . I haven't been following the forum topic federation discussions very closely, so this may be a silly question. Are forum topics going to be fully federated or just replicated (which is not quite the same thing, even for 2-way sync)? For example, if in the future there are 1000's of NodeBB instances running and there's a topic X, is it possible that the posts for that topic could be coming from multiple NodeBB instances (or other instance implementations)? If so, a topic-level canonical link will not work. Google currently indexes individual Mastodon posts (at least some of them, not sure about all of them). The AP Note identifier is the canonical URL in this case. (Google also indexes actor profiles in some cases, but that's a different discussion. ) FWIW, this is the canonical link I see for this topic: I'm guessing the canonical link you quoted is on the NodeBB side? Since these are different canonical links, I'd expect that Google will consider these (SocialHub and NodeBB topics) to be different web resources with mostly replicated content.