diff --git a/content/tech/spec/activitypub/Create.md b/content/tech/spec/activitypub/Create.md new file mode 100644 index 0000000..d0add69 --- /dev/null +++ b/content/tech/spec/activitypub/Create.md @@ -0,0 +1,14 @@ ++++ ++++ + +i have a hard time deciding what ought to be the correct behavior here. maybe activitypub should have just assumed everything is deliverable as-is, but only activities get side-effects? of course there's still a problem with id generation not being fully specified... https://github.com/w3c/activitypub/issues/438 + +something like "generate an id for the outermost object, overriding any pre-included id"? + +which is basically the current behavior and imo where the implicit-create is meant to be applied... basically normalizing everything to an activity (assuming Create by default) + +so without the implicit-create behavior, you would basically POST a note or whatever to your outbox in order to assign it an id, and it would be delivered as-is without the Create. the outbox wouldn't contain only activities, it would also contain objects. this kind of makes the Create itself redundant and unnecessary, i guess? or in other words, you need to define what Create means in terms other than id assignment. this is kind of a problem because right now, Create has "surprisingly few side effects" (read: basically none) + +otherwise you explicitly format every POST as a Create but you have unspecified behavior for id generation of the inner object + +maybe sending a Create C2S does nothing with the inner object, but the side effect should be to assign/register the object on the receiving S2S server? \ No newline at end of file diff --git a/content/tech/spec/activitypub/audience.md b/content/tech/spec/activitypub/audience.md new file mode 100644 index 0000000..696db09 --- /dev/null +++ b/content/tech/spec/activitypub/audience.md @@ -0,0 +1,81 @@ ++++ ++++ + +## what is an "audience" generally + +https://github.com/w3c/activitystreams/issues/18 + +> elf-pavlik: what we consider an audience? other people, groups, circles, lists of contacts … + +> jasnell: Any of these. This is intentionally left open. + +## `audience` used to be `scope` + +https://github.com/w3c/activitystreams/issues/300 + +> The `scope` indicates that the audience for the note is only members of the Organization. +> The `to` indicates specific people who should be actively notified. +> The `context` indicates a larger context within which the note exists. + +so at the very least we can surmise the following points: + +- “to” should actively notify specific actors + - implying that “cc” should passively notify specific actors? or not notify them, just deliver to them? +- “context” is as we already understand it, a purposeful grouping within which the object exists +- “scope” (later “audience”) is some kind of indication of something + +> To be clear: `scope` is not access control… it is closely related to `to`/`bto`/`cc`/`bcc` in that **a consuming implementation can use it to determine who it ought to display the content to**. So, for instance, given the note example above, a consuming implementation may include the note on the activity timeline of anyone associated with the ‘My Employer’ organization, but it would only activity notify two individuals listed by the to property. The `context` property, on the other hand, has absolutely nothing to do with audience targeting. The above note is essentially saying, “This is a note that was created in relation to A Project. Make the note available to anyone in the My Employer organization but specifically notify John and Sally” + +> `scope` is **advisory as to the publishers intent of whose attention they want to draw to the object**. A consuming application may use the scope/to/bto/cc/bcc to determine it’s access control policy if it wishes, but is not required to do so. + +> In the example, a consuming provider could still choose to allow `anyone` to see the note, but only **actively include the note on the activity streams of** people in the company. + +> `scope` could be renamed to `audience` + +https://github.com/w3c/activitystreams/issues/238#issuecomment-153408442 + +> In the AS2 vocabulary, there is a `scope` property that is used generally to identify the audience. **The targeting properties `to`, `bto`, `cc` and `bcc` indicate the audience subsets** within that identified scope. The `context` is really intended to allow objects and activities to be logically grouped. For instance, in an enterprise setting, the context may group activities by project while the scope would identify one or more teams for which the activity is considered relevant, while **the to/cc fields are used to indicate specific individuals to notify**. + +## synthesis time + +https://socialhub.activitypub.rocks/t/overlapping-taxonomies-and-the-audience-property/4229/11 + +i think the use of `audience` is basically “here’s everybody that can/should see this in a feed”. whereas `to` and `cc` are for notification policies (with `to` being intended to actively generate a notification). delivery happens for all of them, but after delivery, the consuming application needs to reconstruct possible intentions. + +BUT + +this doesn’t chime with the current usage by mastodon et al. with mastodon, [audience is generally ignored, only to and cc are considered](https://github.com/mastodon/mastodon/blob/1959365c2f410aa82874c5c05ab92c4eca4c4055/app/lib/activitypub/activity/create.rb#L139), and notifications are instead determined by the presence of a Mention in the tag array. (which imo shouldn’t generate a notification at all? you should be able to mention someone passively if desired.) + +so we have the intended ideal of audience being used for delivering to, well, audience… and to/cc for generating active/passive notifications. but instead, we have a situation where to/cc are used for delivering to an audience, and Mention tags are used for generating notifications (and audience is ignored). + +If we want to have a compatible migration path forward, then for now: + +- `to` should include anyone you want to notify +- `cc` should include everyone else you want to deliver to +- `audience` should include the sum total of both of these? (but if you want to support bto/bcc, then it realistically needs to be a private Collection) + - alternatively, `audience` should include any actors whose feeds / activity-streams should include this activity/object. (this still works out in practice to anyone mentioned, plus your followers, plus probably as:Public – which is likely the union of to and cc anyway) + +sample object/activity targeting for a basic (read: microblogging) use case: + +```yaml +content: "So here's what I have to say..." +inReplyTo: + - attributedTo: + content: "I said something." +to: [] # this should be interpreted as notifying john +cc: [as:Public, ] # this is interpreted as an "unlisted" post in mastodon parlance, and is necessary for delivery to mastodon currently +audience: [, as:Public, ] # this is interpreted as showing in john's home timeline, as well as your follower's home timelines, and also being accessible to anyone without authentication +``` + +so maybe the use of `audience` can address mastodon’s fears of showing “group” posts in home timelines? i know this is a big concern that mastodon brought up with their current groups PR, they very explicitly do not want group posts showing up in home timelines… perhaps some heuristic can be designed so that newer versions of mastodon can filter out posts from home timelines if someone is not included in `audience`? + +sample object/activity targeting for a more complex (read: forum/discussion) use case: + +```yaml +content: "synthesis time. i think the use of audience..." +context: +cc: [as:Public, ] +audience: [as:Public, , , ] +``` + +in this case because `` are not in `audience`, an updated/newer mastodon et al can know not to display this post in my followers’ home feeds. there’s still the sticking issue for mastodon in how they can get older, non-updated mastodon servers to drop the post, although i really think this is foolish, personally… you could still do it by using *only* `audience` and then older mastodon will drop the activity because it doesn’t understand the recipients. \ No newline at end of file diff --git a/config.toml b/hugo.toml similarity index 100% rename from config.toml rename to hugo.toml diff --git a/layouts/partials/seo.html b/layouts/partials/seo.html index bc3c53e..38e1f9f 100644 --- a/layouts/partials/seo.html +++ b/layouts/partials/seo.html @@ -17,7 +17,7 @@ -{{ end }} +{{- end }} {{ "" | safeHTML }} @@ -28,7 +28,7 @@ {{- $cover := ($.Resources.ByType "image").GetMatch "{*cover*,*thumbnail*,*featured*}" -}} {{ $icon := resources.GetMatch (default "" .Site.Params.icon) -}} {{- $staticIcon := "icon.png" | absURL -}} -{{- with or .Params.cover $cover $icon }} +{{- with or $cover $icon }} {{ "" | safeHTML }} @@ -58,7 +58,7 @@ {{- end -}} {{/*=== published and updated ===*/}} -{{ "" | safeHTML }} +{{- "" | safeHTML }} {{ with .Date }} @@ -68,6 +68,7 @@ {{ end -}} {{/*=== section and keywords ===*/}} +{{- "" | safeHTML }} {{- with.Params.category -}} @@ -95,7 +96,7 @@ "dateModified": "{{ .Lastmod.Format "2006-01-02" }}", "image": { "@type": "ImageObject", - "url": "{{ with or .Params.cover $cover $icon }}{{ .Permalink | absURL }}{{ end }}" + "url": "{{ with or $cover $icon }}{{ .Permalink | absURL }}{{ end }}" }, "publisher": { "@type": "Person", @@ -107,7 +108,7 @@ } } -{{- else -}} +{{- else }} {{ "" | safeHTML }}