Skip to content
  • Categories
  • Recent
  • Popular
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

NodeBB-ActivityPub Bridge Test Instance

  1. Home
  2. Categories
  3. General Discussion
  4. AP Test (community.nodebb.org)
  5. How to subscribe to a thread?

How to subscribe to a thread?

Scheduled Pinned Locked Moved AP Test (community.nodebb.org)
activitypubfep
8 Posts 4 Posters 44 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • silverpill@mitra.socialS This user is from outside of this forum
    silverpill@mitra.socialS This user is from outside of this forum
    silverpill@mitra.social
    wrote on last edited by
    #1

    How to subscribe to a thread?

    Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

    So here is an alternative: FEP-f06f: Object observers.

    Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

    #ActivityPub #FEP

    julian@community.nodebb.orgJ helge@socialhub.activitypub.rocksH 2 Replies Last reply
    0
    • silverpill@mitra.socialS silverpill@mitra.social

      How to subscribe to a thread?

      Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

      So here is an alternative: FEP-f06f: Object observers.

      Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

      #ActivityPub #FEP

      julian@community.nodebb.orgJ This user is from outside of this forum
      julian@community.nodebb.orgJ This user is from outside of this forum
      julian@community.nodebb.org
      wrote on last edited by
      #2

      @silverpill@mitra.social I think given the addressing limitations of collections, this by-proxy method of determining who to send an as:Follow to makes sense as a stopgap measure until ActivityPub's next version...

      1 Reply Last reply
      0
      • silverpill@mitra.socialS This user is from outside of this forum
        silverpill@mitra.socialS This user is from outside of this forum
        silverpill@mitra.social
        wrote on last edited by
        #3

        @julian If these limitations don't prevent us from implementing any features, why they should be addressed?

        The entire network is built around the idea that only actors can have inboxes and outboxes. I don't see what problem we solve by challenging this, but I can easily see how that makes things worse.

        trwnh@mastodon.socialT 1 Reply Last reply
        0
        • silverpill@mitra.socialS silverpill@mitra.social

          @julian If these limitations don't prevent us from implementing any features, why they should be addressed?

          The entire network is built around the idea that only actors can have inboxes and outboxes. I don't see what problem we solve by challenging this, but I can easily see how that makes things worse.

          trwnh@mastodon.socialT This user is from outside of this forum
          trwnh@mastodon.socialT This user is from outside of this forum
          trwnh@mastodon.social
          wrote on last edited by
          #4

          @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?

          silverpill@mitra.socialS 1 Reply Last reply
          0
          • trwnh@mastodon.socialT trwnh@mastodon.social

            @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?

            silverpill@mitra.socialS This user is from outside of this forum
            silverpill@mitra.socialS This user is from outside of this forum
            silverpill@mitra.social
            wrote on last edited by
            #5

            @trwnh I didn't say that actors always map to "users", though mapping actors to "accounts" is very common and is a good UI design practice. In my proposal Application actor is recommended, which is not a "user".

            The idea of adding inboxes to collections, or that collections could be followed is not supported by the ActivityPub specification. I believe it is also wrong for other reasons, and I already said enough about that in FEP-2277 and in various discussions.

            @julian

            trwnh@mastodon.socialT 1 Reply Last reply
            0
            • silverpill@mitra.socialS silverpill@mitra.social

              @trwnh I didn't say that actors always map to "users", though mapping actors to "accounts" is very common and is a good UI design practice. In my proposal Application actor is recommended, which is not a "user".

              The idea of adding inboxes to collections, or that collections could be followed is not supported by the ActivityPub specification. I believe it is also wrong for other reasons, and I already said enough about that in FEP-2277 and in various discussions.

              @julian

              trwnh@mastodon.socialT This user is from outside of this forum
              trwnh@mastodon.socialT This user is from outside of this forum
              trwnh@mastodon.social
              wrote on last edited by
              #6

              @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.

              1 Reply Last reply
              0
              • silverpill@mitra.socialS silverpill@mitra.social

                How to subscribe to a thread?

                Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

                So here is an alternative: FEP-f06f: Object observers.

                Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

                #ActivityPub #FEP

                helge@socialhub.activitypub.rocksH This user is from outside of this forum
                helge@socialhub.activitypub.rocksH This user is from outside of this forum
                helge@socialhub.activitypub.rocks
                wrote on last edited by
                #7

                First, one wants a mechanism to subscribe / unsubscribe to a conversation. Having an actor manage it, is a better mechanism than turning the conversation object into a quasi actor.

                I have misgivings, because:

                • The point of using acct-uris is to be more human readable. If one needs to generate them automatically for each thread, this will degrade quickly. IMO it would be better to drop the requirement on webfinger.
                • Generating an observer for each object will lead to a lot of generated public / private keys. I'm not a fan. It would be good to address this somehow. Not sure what the ideal solution would be.
                silverpill@mitra.socialS 1 Reply Last reply
                0
                • helge@socialhub.activitypub.rocksH helge@socialhub.activitypub.rocks

                  First, one wants a mechanism to subscribe / unsubscribe to a conversation. Having an actor manage it, is a better mechanism than turning the conversation object into a quasi actor.

                  I have misgivings, because:

                  • The point of using acct-uris is to be more human readable. If one needs to generate them automatically for each thread, this will degrade quickly. IMO it would be better to drop the requirement on webfinger.
                  • Generating an observer for each object will lead to a lot of generated public / private keys. I'm not a fan. It would be good to address this somehow. Not sure what the ideal solution would be.
                  silverpill@mitra.socialS This user is from outside of this forum
                  silverpill@mitra.socialS This user is from outside of this forum
                  silverpill@mitra.social
                  wrote on last edited by
                  #8

                  1. +1. I will replace webfinger address recommendation with a warning about possible compatibility issues.
                  2. I think observers (and other Application actors on the server) should use a shared key.

                  1 Reply Last reply
                  0
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                  • Login

                  • Login or register to search.
                  Powered by NodeBB Contributors
                  • First post
                    Last post
                  0
                  • Categories
                  • Recent
                  • Popular