@evanminto

Did you intentionally remove paging from the Outbox?

Yes, since nothing is gonna use the outbox at first I opted not to introduce that yet.

If I'm reading this right, the fragment identifier #create doesn't match the spec

https://octodon.social/users/cwebber/updates/143857

List the Create activities wrapping the objects.
If you don't have Create activities as separate objects, you could do a hack with a "fragment identifier" like so:
{"id": "https://mastodon.social/users/Gargron/updates/3243062#create",
"type": "Create",
"object": {"type": "Note", "id": https://mastodon.social/users/Gargron/updates/3243062"}}

Re: Outbox, sounds good.

Re: #create, I'm... not sure I agree with Chris on that, though they're the spec co-author and I'm not. I want to double-check with them about it.

@evanminto I talked to chris about this earlier, and I think the understanding we came to is that using fragments does count as publicly dereferenceable, because you can make the request and then use the object it returns. (using an algorithm to select the correct fragment identifier—json-ld is somewhat unclear on this, so we were considering including a guideline in activitypub on how to dereference fragment identifiers)

I have addressed the concern by turning the create URI to "/create" instead of "#create"

I have also added representation of hashtags and mentions, although hashtag representation is incomplete (spec is unclear). Also, sensitivity of the content still cannot be encoded in AP.

For the record—I think that #create is still the right way to go about this. this was from the conversation I had with @cwebber about resolving fragment identifiers

I think the best thing to do is to fetch the object at the uri, then search through the returned as2 object for the sub-object with the fragment. Similar to how you'd "jump" to the right section in html based on the fragment.

https://octodon.social/users/cwebber/updates/143916

and the original issue discussion:

w3c/activitypub#224

@nightpool I had a later conversation with Chris about this as well. The problem is that "create" is above the "note" in hierarchy, so it wouldn't work that way - there is no reason for note JSON to return the create activity.

Another option is something like

{
    "id": "https://mastodon.social/users/Gargron/updates/3243062",
    "type": "Create",
    "object":  {
        "type": "Note",
        "id": null
    }
}

which is also supported by the spec (the two objects share the same identifier)

@Gargron This is why I think it needs to be hashed out a little more in the spec itself, but I would say the algorithm would be something like:

1. dereference the URI into a JSON object
2. find the JSON object in that document with an "id" equal to the URI you are trying to dereference

this would work in both cases?

@evanminto Okay, I rewrote all this stuff with serializers, which I think is a lot cleaner now.

However, the difference between Create/Announce and Note is really blurry still. For example! A local status can be a reblog, aka a wrapper around another status. So what to do when its URI is directly accessed? It's technically among the notes URIs, but it would need to be an Announce (or web redirect to URI of original?) It is the most frustrating thing. I suggest we leave this as-is and then adjust in future PRs.

I would also like to involve @cwebber in writing down an audience matrix for all of our visibility levels. There's cc, to, bcc, bto; and there's public, unlisted, followers+mentions-only and mentions-only (direct), and I have no good idea which values to fill in where.

The activity/object thing has been resolved.

I would also like to involve @cwebber in writing down an audience matrix for all of our visibility levels. There's cc, to, bcc, bto

The difference between to and cc is IMO mostly presentational; to is the primary audience while cc is secondary. You have a lot of flexibility to interpret that as you like since delivery will happen the same way. bcc and bto... imo there's no reason to have bto because since these are both removed, there's nothing presentational about it...! It can only be the origin server that plans to do anything different between primary/secondary for those blind address slots.

and there's public, unlisted, followers+mentions-only and mentions-only (direct), and I have no good idea which values to fill in where.

Public post should be like:

{"to": ["https://www.w3.org/ns/activitystreams#Public"],
 "cc": ["https://social.example/alyssa/followers/"], ...}

(again, you can swap out to/cc as you wish, it barely matters, just my suggestion)

Followers-Only vs Unlisted? I'm not sure what the difference is, it seems to me that they're the same:

{"to": ["https://social.example/alyssa/followers/"], ...}

I guess the difference is that one of them really is public but just doesn't get inserted in the Public timeline? I'm not sure how to differentiate these though.

followers+mentions-only:

{"to": ["https://social.example/alyssa/followers/"]
 "cc": ["https://chatty.example/ben/"],
 "tag": [{"type": "Mention", "href": "https://chatty.example/ben/", "name": "@ben"}],
  ...}

mentions-only:

{"to": ["https://chatty.example/ben/"],
 "tag": [{"type": "Mention", "href": "https://chatty.example/ben/", "name": "@ben"}],
  ...}

Again, you have a lot of freedom on where to put to/cc.

@cwebber Implemented.

@evanminto Pls re-review.

My two cents on the ActivityPub side: It seems the outbox has no id value, so my server refuses to load it in. The activities and objects though, it has no issue with it, no changes to either side of the connection.

.. however, the announces use a local object, and as such I can't use ActivityPub when getting stuff from a Mastodon server.

however, the announces use a local object, and as such I can't use ActivityPub when getting stuff from a Mastodon server.

@puckipedia Please explain. It would return the object with a remote URI and all of its remote data as we know it, so it should be fine - the most important part being the ID. So what's wrong?

I tested it out with a local server, and searched for https://mastodon.social/users/Gargron/updates/1 and then boosted it - this results in a proper status being loaded in the database, but the activitypub representation shows the actor being my instance's admin.

I am pretty sure this is because the object it's serializing is actually the boost, and, not the original status that was boosted. (local? seems to return true for the object that gets serialized into an Announce)

@puckipedia mastodon.social isn't running this PR! it's running 1.4.7. there is no live instance which uses this PR since it's not merged

Okay, I found a more simple way: if I post a status on the admin account (which gets the url https://example.com/users/admin/statuses/4), and then boost it (even from the same account), the object contained in the Announce points to https://example.com/users/admin/statuses/5.

While checking that, I realised I think it's best to add the audience (so to and cc) to the Activity too, as that may differ from the containing object

@puckipedia Fixed!

Yay, that works! Kroeg now seems to have no issue loading the ActivityPub data!