streams

[evanp]

Users in pump.io can use lists to organize their contacts. They can post a note or image to a list, and only members of that list will receive the note or image.

Is this what streams is for? If not, what's it for? And is it a collection, or something else?

[kaniini]

I believe streams is meant to be used for that.

Groups are actors which announce anything sent to their inbox.

I'm interested in implementing both of those for pleroma, incidentally.

[cwebber]

streams is an array of Collections, and it's for the thing you suggested.

[aschrijver]

The description of streams ("A list of supplementary Collections which may be of interest.") is a bit short, which can lead to confusion.

Also isn't it _"An array of links to Collections"? Just like followers is described as "A link to an [ActivityStreams] collection .."

Note that for inbox/outbox there is mention of a reference to the collection. I assume in all cases, link, reference, array of collections this refers to adding URI's?

[trwnh]

semi-related: is there a way to post to arbitrary Collections of content, instead of arbitrary Collections of contacts? or is there / should there be a separate issue for that? as in, arbitrary subsets of outbox?

[evanp]

Unless there's a reason to keep this open, I'm good with closing it.

[transfluxus]

there seem to be quite a few open questions. unless they can be answered or go to new issues maybe we keep it open, ... for discussion

[cjslep]

Also isn't it _"An array of links to Collections"? Just like followers is described as "A link to an [ActivityStreams] collection .."

Note that for inbox/outbox there is mention of a reference to the collection. I assume in all cases, link, reference, array of collections this refers to adding URI's?

The way I read it: link and reference are redundant language referring to the IRI_reference portion of the JSON-LD spec. So the language of the streams bit leaves it open to either be the Collection itself literally_embedded, or (as always permitted by JSON-LD) the IRI_reference. The inbox and outbox are restricted to only being the IRI reference bit of JSON-LD, and not the literal value embedded (as would otherwise be permitted, but explicitly not included by ActivityPub).

Thus it could be...

...fully embedded:

{
  "streams":  [
    {
      id: "http://example.com/collection/1",
      type: "Collection"
    },
    {
      id: "http://example.com/collection/2",
      type: "OrderedCollection"
    },
    {
      id: "http://example.com/collection/3",
      type: "Collection"
    }
  ]
}

...IRI reference only

{
  "streams":  [
    "http://example.com/collection/1",
    "http://example.com/collection/2",
    "http://example.com/collection/3"
  ]
}

...mixed

{
  "streams":  [
    "http://example.com/collection/1",
    "http://example.com/collection/2",
    {
      id: "http://example.com/collection/3",
      type: "Collection"
    }
  ]
}

...single-value-as-array-of-length-one full value

{
  "streams": {
      id: "http://example.com/collection/1",
      type: "Collection"
  }
}

...single-value-as-array-of-length-one by IRI reference

{
  "streams": "http://example.com/collection/1"
}

semi-related: is there a way to post to arbitrary Collections of content, instead of arbitrary Collections of contacts? or is there / should there be a separate issue for that? as in, arbitrary subsets of outbox?

I think streams would be good for that as well, since it's vague enough to be a grab-bag of different kinds of lists.

[aschrijver]

Thank you! That clears it up :)

[aschrijver]

Coming back to this, after a while. I am curious if there are federated apps that currently use streams in production, and what they use it for. How do you use streams in an interoperable way, when e.g. having IRI reference in no way communicates what is in the referenced collection. There's no semantics other than 'arbitrary stream' attached to this property, right?

I gathter that, if for instance defining a Community domain as AP extension, there's no use for stream to define the interpersonal relationships as a collection on an actor. In that case an extension property e.g. co:relationships looks more appropriate (with co the extension namespace prefix).

[ap-socialhub]

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

https://socialhub.activitypub.rocks/t/where-are-the-range-and-functional-of-activitypub-properties-defined/2761/4

[evanp]

After 5 years, this feature of ActivityPub continues to be underspecified and underimplemented.

For my original question, exposing contact lists that can be addressed in to, cc, etc. is not covered very well by the streams property. It would make more sense to define a new actor property, e.g. lists or contactLists, that provides more specific guidelines for publishing and using these entities.

I'm taking it as a task to write a FEP for this property, since I think it's useful, and contact lists are already defined in for example Mastodon.

I don't think there is a resolution here for the streams property. The best I think we can do is capture best practices on the primer. I've done this here:

https://www.w3.org/wiki/ActivityPub/Primer/Streams

[evanp]

Closed after several weeks. Thanks all!