membership endpoint

[evanp]

For a collection with id https://social.example/collection/1 and an object with id https://social.example/object/1, the only way for a client to know if the object is in the collection is to fetch the whole collection page by page and check all the items to see if the object id matches. This is pretty expensive!

This could be sped up considerably if the collection server can do the lookup instead of the client. It would be interesting to have an extension property for such an endpoint.

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      "https://extension.example/membership"
  ],
  "type": "Collection",
  "membership": "https://social.example/collection/1/membership",
  "totalItems": 100000
}

Like the proxyUrl, it could accept a single POST parameter, id. Unlike proxyUrl, it would return a single boolean value, true or false.

[nightpool]

What's the user story for this? followers collections?

On Mon, Aug 26, 2024, 2:43 PM Evan Prodromou @.***> wrote:

For a collection with id https://social.example/collection/1 and an object with id https://social.example/collection/1, the only way for a client to know if the object is in the collection is to fetch the whole collection page by page and check all the items to see if the object id matches. This is pretty expensive!

This could be sped up considerably if the collection server can do the lookup instead of the client. It would be interesting to have an extension property for such an endpoint.

{ @.***": [ "https://www.w3.org/ns/activitystreams", "https://extension.example/membership" ], "type": "Collection", "membership": "https://social.example/collection/1/membership", "totalItems": 100000 }

Like the proxyUrl, it could accept a single POST parameter, id. Unlike proxyUrl, it would return a single boolean value, true or false.

— Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV3M2VFE2GBE43CY7M3ZTOAN7AVCNFSM6AAAAABNEVCVJKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ4DONRTGQYDGMI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[snarfed]

@nightpool yup, one example is showing a "follows you" badge on someone's profile when you view it.

[nightpool]

wouldn't that be metadata that it would be easier for your local server (which is presumably authenticating your requests, at the very very least) to have stored in its cache though?

Because it has to keep track of that information anyway to distribute your posts to your followers / show you posts of people you follow.

On Mon, Aug 26, 2024, 4:48 PM Ryan Barrett @.***> wrote:

@nightpool https://github.com/nightpool yup, one example is showing a "follows you" badge on someone's profile when you view it.

— Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/462#issuecomment-2311158466, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV35H6RUAQ7VF5RV4Y3ZTOPBJAVCNFSM6AAAAABNEVCVJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJRGE2TQNBWGY . You are receiving this because you were mentioned.Message ID: @.***>

[snarfed]

Maybe! As a cache, sure. But even if your local server does it, it's expensive for profiles that follow many people. And ideally something you want to refresh, not just check once.

[nightpool]

WDYM "check once"? your local server is the authority for your own followers and following collections. If the remote server disagrees then you're sending posts to the wrong people and that's an even bigger problem

[snarfed]

Ah, true! You're right, the obvious easier answer is to check the user's own followers collection.

[nightpool]

A different user story where we considered this type of approach was described in FEP-8f8c (trying to find "ghost followers", or places where local and remote followers and following collections have gotten out of sync) but we decided that a 1-by-1 membership query approach like this issue suggests was too slow and inefficient for the ghost followers user story.

One of the reasons I bring up the user story question here is because I want to make sure we're using the right tools for the right problems, but another reason is because adding "set operations" type queries to Collections immediately raises the question of what other type of set operations Collections should support (filter, sort, find by domain, etc), and having a clear user story would make it easier to build a more useful set of operations and motivate their adoption by implementers.

[snarfed]

Yes! Agreed.

Bluesky recently added a similar user story that uses similar set operations. When you view someone's profile, they show you whether any of your followings follow that person. Eg Alice follows Bob, Alice views Eve's profile, she sees "Bob follows Eve." This needs set intersection between Eve's followers and Alice's following.

(I think Bluesky ended up using bloom filters for this instead, but still!)

[nightpool]

yeah, we also used a solution involving fixed size bloom esque hashes. I think that's a more promising/useful future extension for implementors than this approach

On Mon, Aug 26, 2024, 5:32 PM Ryan Barrett @.***> wrote:

Yes! Agreed.

Bluesky recently added a similar user story that uses similar set operations. When you view someone's profile, they show you whether any of your followings follow that person. Eg Alice follows Bob, Alice views Eve's profile, she sees "Bob follows Eve." This needs set intersection between Eve's followers and Alice's following.

(I think Bluesky ended up using bloom filters for this instead, but still!)

— Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/462#issuecomment-2311343248, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV4SMA5XCMKJTXU27WTZTPCIHAVCNFSM6AAAAABNEVCVJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJRGM2DGMRUHA . You are receiving this because you were mentioned.Message ID: @.***>

[trwnh]

prior art: smithereen has a collectionSimpleQuery endpoint

also related: SPARQL would probably address the following point

adding "set operations" type queries to Collections immediately raises the question of what other type of set operations Collections should support (filter, sort, find by domain, etc)

[evanp]

What's the user story for this? followers collections?

I think the main one would be for authorizing followers/following. Here's an example:

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "id": "https://server1.example/user/a/note/1",
   "type": "Note",
   "content": "Hello, World!",
   "attributedTo": "https://server1.example/user/a",
   "to": "https://server1.example/user/a/followers",
   "replies": {
        "type": "Collection",
        "id": "https://server1.example/user/a/note/1/replies",
        "items": [
            {
                "type": "Note",
                "id": "https://server2.example/user/b/note/2",
                "attributedTo": "https://server2.example/user/b",
                "to": ["https://server1.example/user/a", "http://server1.example/user/a/followers"]
            }
        ]
   }
}

Here, we have one note by user a@server1.example, with one reply by b@server2.example. If a@server1.example requests the reply object, it should be authorized, since a is addressed in the note. However, if a's follower c@server3.example requests the same note, they have authorization to view it, since they're a member of a's followers collection, but it takes server2 a while to iterate through that collection and find c@server3. The membership endpoint would make that much quicker.

Note: the replies collection is expanded here; in many cases it will only include URIs in the items, or even be represented by an URI itself (also, like 1000 other ways that collections are represented!).

[ap-socialhub]

This issue has been mentioned on SocialHub. There might be relevant details there:

https://socialhub.activitypub.rocks/t/fep-c7d3-ownership/4292/20

[nightpool]

I am hesitant to reify that as a valid use case because very few servers are going to want to expose the following / followers collection publicly. For example, twitter protected accounts don't expose that collection.

But the delegated auth use case is a very important one... Right now it's handled entirely by Inbox Forwarding. We should come up with a list of limitations of the inbox forwarding approach and see if we can find some solutions there

On Fri, Aug 30, 2024, 10:03 AM SocialHub @.***> wrote:

This issue has been mentioned on SocialHub. There might be relevant details there:

https://socialhub.activitypub.rocks/t/fep-c7d3-ownership/4292/20

— Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/462#issuecomment-2321989809, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV3XTBF25LEO5LHWY6LZUCQXLAVCNFSM6AAAAABNEVCVJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRRHE4DSOBQHE . You are receiving this because you were mentioned.Message ID: @.***>