A single object within the attachment property does not serialize as an array

[gabek]

I'm guessing this is similar as #139, just with a different property.

For Mastodon it expects the attachment property within an actor to be an array, even just with a single item. Is there any way to force the serialization of this to be an array of items, instead of just the single object assigned to the attachment property?

Add a single object under "attachment" and it does not correctly serialize as an array:

"attachment": {
  "name": "github",
  "type": "PropertyValue",
  "value": "<a href=\"https://github.com/owncast/owncast\" rel=\"me nofollow noopener noreferrer\" target=\"_blank\">https://github.com/owncast/owncast</a>"
},

Add multiple objects under "attachment" and it correctly serializes as an array.

"attachment": [
  {
    "name": "github",
    "type": "PropertyValue",
    "value": "<a href=\"https://github.com/owncast/owncast\" rel=\"me nofollow noopener noreferrer\" target=\"_blank\">https://github.com/owncast/owncast</a>"
  },{
    "name": "github",
    "type": "PropertyValue",
    "value": "<a href=\"https://github.com/owncast/owncast\" rel=\"me nofollow noopener noreferrer\" target=\"_blank\">https://github.com/owncast/owncast</a>"
  }
]

[cjslep]

I'd open an issue with Mastodon, as this is a valid ActivityStreams representation they should be able to handle.

[cjslep]

Note that there is no trivial fix for go-fed, unfortunately. The post in #139 outlines the difficulty for any property, attachment or otherwise.

Furthermore, if go-fed is expected to craft special ActivityStream flavors on a per-peer-software basis, things get very complicated very fast. In principle it is a problem I would rather not solve in go-fed, and instead tell peer software to handle receiving ActivityStreams data more robustly (as go-fed already does).

I can walk you through why this problem is dangerously intractable: to begin, this is a major violation of go-fed's design principle of "generate once work everywhere" style of ActivityStreams solution. What this implies is that there is a Dialect concept for certain peer software (here, the "mastodon dialect") so that go-fed knows how to "style" certain ActivityStreams data for that Dialect. "Style" meaning "choosing [<value>] instead of <value> for 1 element", for example. This complicates your client code too: You'd need to know which peers are running which software and then "style" the ActivityStreams payload.

Where it becomes intractable is this: let us say you want to interoperate with a second peer software, let us call it FooBarFed, and it has a conflicting style since it isn't robust enough to handle the mastodon style. How do you style the same message twice, without having to generate a second id property? If a mastodon peer and FooBarFed peer each try to dereference your id, now you're having to guess what kind of client you're serving, and dynamically determine how to "style" the view of the same AS data for the dereferencing peer, in order to keep the same id. Or, have two ids (yet in your UI, somehow collapse them into the "same" message. Ditto for your peer softwares that understand both "dialects" but don't have the Dialect concept -- they'll double-display). Very messy.

Then, this scales into brokenness as N peer softwares do not robustly handle incoming ActivityStreams data into N different ids, or N different "peer-detection" algorithms.

I would rather the peer software simply be more robust in what ActivityStreams data it accepts. Instead of opening the above can of worms.

EDIT: The robustness principle of "be conservative in what you do, be liberal in what you accept from others" applies here.

[gabek]

Thanks for the clarification, that's what I figured. Closing!