This commit is contained in:
a 2022-12-24 13:29:28 -06:00
parent ec503b12b9
commit e7ea9800f0
4 changed files with 186 additions and 3 deletions

View file

@ -13,11 +13,9 @@ p, h1, h2, h3, h4, h5, h6 {
overflow-wrap: break-word;
}
img, picture, video, canvas, svg,
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section {
display: block;
max-width: 100%;
}
input, button, textarea, select {

View file

@ -0,0 +1,77 @@
# Note vs Article
Discussion: <https://socialhub.activitypub.rocks/t/resolving-the-note-vs-article-distinction/258>
in summary:
> Note: Represents a short written work typically less than a single paragraph in length.
> Article: represents any kind of multi-paragraph written work.
but this is contradicted by as2/ap examples
## failed ideas for distinction
### a "paragraph"
perhaps a note could have no line breaks or only a single `<p>` tag, while an article does? well there's an example that directly contradicts this! ActivityPub example 4 uses two `<p>` tags inside a Note's content
### titles
some say a Note has no title but an Article does -- this is not strictly true in all cases, a Note can have a `name` (and AS2-Vocab example 43 does so)
### formatting
some say a Note has no formatting but an Article does -- this is not true at all, as Note can be HTML and is in fact assumed to be HTML by default (per AS2-Vocab definition of `mediaType`)
### length
perhaps a Note has some character limit and an Article doesn't -- but what is the limit? completely arbitrary. not worth making this distinction
## what's left for distinction?
### syndication
an Article is expected to be syndicated (think HTML `<article>`) since it is a self-contained piece of content. whereas a Note might not be
however this may imply that microblog posts should be sent out as Article? requires further thought
### formality
an Article is "published" in a formal context whereas a Note is presented in an informal context
in other words a Note may be ephemeral while an Article is longer-lived
## the practical difference
a Note will be displayed inline in Mastodon, but an Article will be converted to name/summary + url/id
further recommendations for microblog compatibility:
- a Note SHOULD still work with a plaintext fallback, as most html will be stripped
- a Note SHOULD NOT have a name/title, as this will be ignored
if you don't care about Mastodon or similar microblogging impls then do whatever
## indieweb perspective
indieweb seems to take this view <https://indieweb.org/Semantics_Of_Article-Note_Distinction>
> post name/title [though discounted above]
> non-trivial structure [akin to formality -- headings?]
> plain text vs markup [basically the p-content vs e-content argument]
## takeaway thoughts
i would tend to assume everything is an article by default, with certain characteristics making it tend toward being a note instead
for metadata:
- no name?
for content:
- no headings?
- no formatting?

View file

@ -1,3 +1,79 @@
# Actor
an actor is just something that has `inbox` and `outbox`
an actor is just something that has `inbox` and `outbox`
{{<toc>}}
## implementations
### mastodon
mastodon only understands Person / Group / Organization / Application / Service due to being overly strict -- [mastodon/mastodon#22322](https://github.com/mastodon/mastodon/issues/22322)
### pleroma
ostensibly pleroma is also limited in the same way? https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/constants.ex#L57
other references in code:
- admin api param `actor_types` only takes Person Service Application https://git.pleroma.social/pleroma/pleroma/-/blob/develop/docs/development/API/admin_api.md#L25
- Pleroma.Object.Containment#get_actor filters against Person Service Application https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/object/containment.ex#L22
- Pleroma.Web.ActivityPub.ActivityPub#maybe_update_follow_information checks that user type against Person Service https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/activity_pub/activity_pub.ex#L1608
- SimplePolicy checks for Application Group Organization Person Service https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/activity_pub/mrf/simple_policy.ex#L230
- openapi spec schema defines enum Application Group Organization Person Service https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/api_spec/schemas/actor_type.ex#L11
### misskey
the isActor check only validates if one of the five types
the interface requires `inbox`, `outbox` so that's fine
https://github.com/misskey-dev/misskey/blob/22ccb0fa716a84560c8599781647baaaeb8e80bd/packages/backend/src/core/activitypub/type.ts#L150-L176
```js
export const validActor = ['Person', 'Service', 'Group', 'Organization', 'Application'];
export const isActor = (object: IObject): object is IActor =>
validActor.includes(getApType(object));
export interface IActor extends IObject {
type: 'Person' | 'Service' | 'Organization' | 'Group' | 'Application';
name?: string;
preferredUsername?: string;
manuallyApprovesFollowers?: boolean;
discoverable?: boolean;
inbox: string;
sharedInbox?: string; // 後方互換性のため
publicKey?: {
id: string;
publicKeyPem: string;
};
followers?: string | ICollection | IOrderedCollection;
following?: string | ICollection | IOrderedCollection;
featured?: string | IOrderedCollection;
outbox: string | IOrderedCollection;
endpoints?: {
sharedInbox?: string;
};
'vcard:bday'?: string;
'vcard:Address'?: string;
}
```
### gotosocial
https://github.com/superseriousbusiness/gotosocial/blob/d445c60a26e7f51f6d742e992d15cb5fabe2100c/internal/federation/dereferencing/account.go#L412-L478
seems to have a switch-case for Application Group Organization Person Service, but the comment above dereferenceAccountable() says this only (currently?) works for Person Application Service
### peertube
https://github.com/Chocobozzz/PeerTube/blob/develop/shared/models/activitypub/activitypub-actor.ts
seems to have required fields `type` `id` `following` `followers` `inbox` `outbox` `preferredUsername` `url` `name` `endpoints.sharedInbox` `summary` `attributedTo` `publicKey` `publicKey.id` `publicKey.owner` `publicKey.publicKeyPem` [whew that's a lot!]

View file

@ -0,0 +1,32 @@
# Flag
used for reports
## sample payload
### mastodon
```http
POST /users/1/inbox HTTP/1.1
Host: friends.grishka.me
Content-Type: application/activity+json
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://mastodon.social/ccb4f39a-506a-490e-9a8c-71831c7713a4",
"actor": "https://mastodon.social/actor",
"content": "Please disregard this report. I'm just testing report federation.",
"object": [
"https://friends.grishka.me/users/1",
"https://friends.grishka.me/posts/380590"
]
}
```
notes:
- it is sent to the reported account's `inbox` -- [ReportService#forward_to_origin!](https://github.com/mastodon/mastodon/blob/c4a429ed47e85a6bbf0d470a41cc2f64cf120c19/app/services/report_service.rb#L51)
- [arguably this should be sent to a `sharedInbox` if available? or an instance actor if detected somehow? idk]
- [mastodon uses the wrong content-type currently -- [mastodon/mastodon#22720](https://github.com/mastodon/mastodon/issues/22720)]
- the first item in `object` is the user
- additional items in `object` are attached statuses
- [shouldn't these be in `attachment` instead?]