Salta al contenuto
Citiverse è uno spazio aperto a tutte le comunità. Se vuoi aprire un gruppo locale o una sezione per la tua organizzazione, puoi contattare gli amministratori: pagina dei contatti.

One thing I find challenging with the #ActivityPub spec is that the terminology is very loose.

General Discussion
6 3 0
  • scritto ultima modifica di
    #1

    One thing I find challenging with the spec is that the terminology is very loose. Some examples are the way (API) "endpoint", "collection", and "stream" are used. Posting to an inbox endpoint is not the same as adding an activity to an (optional) inbox collection. A reverse-chronological collection of events is a history of an event stream, not the stream itself. I think conflating these concepts leads to much confusion. See the AP "streams" property, for example.

  • One thing I find challenging with the spec is that the terminology is very loose. Some examples are the way (API) "endpoint", "collection", and "stream" are used. Posting to an inbox endpoint is not the same as adding an activity to an (optional) inbox collection. A reverse-chronological collection of events is a history of an event stream, not the stream itself. I think conflating these concepts leads to much confusion. See the AP "streams" property, for example.

    scritto ultima modifica di
    #2

    I think an interesting statement from Chapter 3 of the spec is "Objects are often wrapped in Activities and are contained in streams of Collections" (different than the collection/stream conflation). However, the meaning of "streams of Collections" is defined nowhere. It's also interesting to me that "stream" has no normative definition in the Activity Streams 2.0 spec although it's in the name! The pre-W3C 1.0 version did define an Activity Stream as a collection, so ... 🤷‍♂️

  • I think an interesting statement from Chapter 3 of the spec is "Objects are often wrapped in Activities and are contained in streams of Collections" (different than the collection/stream conflation). However, the meaning of "streams of Collections" is defined nowhere. It's also interesting to me that "stream" has no normative definition in the Activity Streams 2.0 spec although it's in the name! The pre-W3C 1.0 version did define an Activity Stream as a collection, so ... 🤷‍♂️

    scritto ultima modifica di
    #3

    @Steve_Bate

    There's a long-standing issue and recognition that streams is underspecified..

    https://github.com/w3c/activitypub/issues/299

  • One thing I find challenging with the spec is that the terminology is very loose. Some examples are the way (API) "endpoint", "collection", and "stream" are used. Posting to an inbox endpoint is not the same as adding an activity to an (optional) inbox collection. A reverse-chronological collection of events is a history of an event stream, not the stream itself. I think conflating these concepts leads to much confusion. See the AP "streams" property, for example.

    scritto ultima modifica di
    #4

    @Steve_Bate

    What? Inserting into a database table isn't the same as POSTing to an API endpoint that does this anywhere else either.

  • @Steve_Bate

    There's a long-standing issue and recognition that streams is underspecified..

    https://github.com/w3c/activitypub/issues/299

    scritto ultima modifica di
    #5

    @smallcircles Yes, that 2018 issue is a great example of what appears to be conceptual confusion between collections and streams. Calling a collection of contacts (the use case described in the issue) a "stream" is strange. The problem is that streams can't be specified well until we decide what they are. I see this issue recurring in the AP C2S discussions. https://github.com/swicg/activitypub-api/issues/37

  • @Steve_Bate

    What? Inserting into a database table isn't the same as POSTing to an API endpoint that does this anywhere else either.

    scritto ultima modifica di
    #6

    @nik Yes, that's why I think it's confusing that the AP spec loosely communicates them as if they are the same.


Citiverse è un progetto che si basa su NodeBB ed è federato! | Categorie federate | Chat | 📱 Installa web app o APK | 🧡 Donazioni | Privacy Policy

Il server utilizzato è quello di Webdock, in Danimarca. Se volete provarlo potete ottenere il 20% di sconto con questo link e noi riceveremo un aiuto sotto forma di credito da usare proprio per mantenere Citiverse.