mirror of https://gitlab.com/bashrc2/epicyon
Merge branch 'main' of gitlab.com:bashrc2/epicyon
commit
da68d7729a
|
@ -339,6 +339,7 @@ def markdown_to_html(markdown: str) -> str:
|
||||||
ctr = 0
|
ctr = 0
|
||||||
code_section = False
|
code_section = False
|
||||||
titles = {
|
titles = {
|
||||||
|
"h6": '######',
|
||||||
"h5": '#####',
|
"h5": '#####',
|
||||||
"h4": '####',
|
"h4": '####',
|
||||||
"h3": '###',
|
"h3": '###',
|
||||||
|
|
|
@ -346,7 +346,7 @@ For example, Alyssa P. Hacker likes to post to her ActivityPub powered blog via
|
||||||
ActivityPub actors are generally one of the [ActivityStreams Actor Types](https://www.w3.org/TR/activitystreams-vocabulary/#actor-types), but they don't have to be. For example, a [Profile](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-profile) object might be used as an actor, or a type from an [ActivityStreams](https://www.w3.org/TR/activitystreams-core) extension. Actors are retrieved like any other Object in ActivityPub. Like other [ActivityStreams objects](https://www.w3.org/TR/activitystreams-vocabulary/#object-types), actors have an `id`, which is a URI. When entered directly into a user interface (for example on a login form), it is desirable to support simplified naming. For this purpose, ID normalization *SHOULD* be performed as follows:
|
ActivityPub actors are generally one of the [ActivityStreams Actor Types](https://www.w3.org/TR/activitystreams-vocabulary/#actor-types), but they don't have to be. For example, a [Profile](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-profile) object might be used as an actor, or a type from an [ActivityStreams](https://www.w3.org/TR/activitystreams-core) extension. Actors are retrieved like any other Object in ActivityPub. Like other [ActivityStreams objects](https://www.w3.org/TR/activitystreams-vocabulary/#object-types), actors have an `id`, which is a URI. When entered directly into a user interface (for example on a login form), it is desirable to support simplified naming. For this purpose, ID normalization *SHOULD* be performed as follows:
|
||||||
|
|
||||||
* If the entered ID is a valid URI, then it is to be used directly.
|
* If the entered ID is a valid URI, then it is to be used directly.
|
||||||
* If it appears that the user neglected to add a scheme for a URI that would otherwise be considered valid, such as `example.org/alice/`, clients *MAY* attempt to provide a default scheme, preferably `https`.
|
* If it appears that the user neglected to add a scheme for a URI that would otherwise be considered valid, such as `example.org/users/alice`, clients *MAY* attempt to provide a default scheme, preferably `https`.
|
||||||
* Otherwise, the entered value should be considered invalid.
|
* Otherwise, the entered value should be considered invalid.
|
||||||
|
|
||||||
Once the actor's URI has been identified, it should be dereferenced.
|
Once the actor's URI has been identified, it should be dereferenced.
|
||||||
|
@ -356,42 +356,97 @@ Once the actor's URI has been identified, it should be dereferenced.
|
||||||
ActivityPub does not dictate a specific relationship between "users" and Actors; many configurations are possible. There may be multiple human users or organizations controlling an Actor, or likewise one human or organization may control multiple Actors. Similarly, an Actor may represent a piece of software, like a bot, or an automated process. More detailed "user" modelling, for example linking together of Actors which are controlled by the same entity, or allowing one Actor to be presented through multiple alternate profiles or aspects, are at the discretion of the implementation.
|
ActivityPub does not dictate a specific relationship between "users" and Actors; many configurations are possible. There may be multiple human users or organizations controlling an Actor, or likewise one human or organization may control multiple Actors. Similarly, an Actor may represent a piece of software, like a bot, or an automated process. More detailed "user" modelling, for example linking together of Actors which are controlled by the same entity, or allowing one Actor to be presented through multiple alternate profiles or aspects, are at the discretion of the implementation.
|
||||||
|
|
||||||
### 4.1 Actor objects
|
### 4.1 Actor objects
|
||||||
Actor objects *MUST* have, in addition to the properties mandated by section 3.1 Object Identifiers, the following properties:
|
|
||||||
|
|
||||||
#### 4.1.1 inbox
|
As the upstream vocabulary for ActivityPub, any applicable [ActivityStreams](https://www.w3.org/TR/activitystreams-core) property may be used on ActivityPub Actors. Some ActivityStreams properties are particularly worth highlighting to demonstrate how they are used in ActivityPub implementations.
|
||||||
|
|
||||||
|
Properties containing natural language values, such as `name`, `preferredUsername`, or `summary`, make use of [natural language support defined in ActivityStreams](https://www.w3.org/TR/activitystreams-core/#naturalLanguageValues).
|
||||||
|
|
||||||
|
#### 4.1.1 Actor objects *MUST* have, in addition to the properties mandated by section 3.1 Object Identifiers, the following properties:
|
||||||
|
|
||||||
|
##### inbox
|
||||||
A reference to an ActivityStreams [OrderedCollection](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection) comprised of all the messages received by the actor; see section 5.2 Inbox.
|
A reference to an ActivityStreams [OrderedCollection](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection) comprised of all the messages received by the actor; see section 5.2 Inbox.
|
||||||
|
|
||||||
#### 4.1.2 outbox
|
##### outbox
|
||||||
An ActivityStreams [OrderedCollection](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection) comprised of all the messages produced by the actor; see section 5.1 Outbox.
|
An ActivityStreams [OrderedCollection](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollection) comprised of all the messages produced by the actor; see section 5.1 Outbox.
|
||||||
|
|
||||||
Implementations *SHOULD*, in addition, provide the following properties:
|
##### following
|
||||||
|
|
||||||
#### 4.1.3 following
|
|
||||||
A link to an [ActivityStreams collection](https://www.w3.org/TR/activitystreams-core/#collections) of the actors that this actor is following; see section 5.4 Following Collection
|
A link to an [ActivityStreams collection](https://www.w3.org/TR/activitystreams-core/#collections) of the actors that this actor is following; see section 5.4 Following Collection
|
||||||
|
|
||||||
#### 4.1.4 followers
|
##### followers
|
||||||
A link to an [ActivityStreams collection](https://www.w3.org/TR/activitystreams-core/#collections) of the actors that follow this actor; see section 5.3 Followers Collection.
|
A link to an [ActivityStreams collection](https://www.w3.org/TR/activitystreams-core/#collections) of the actors that follow this actor; see section 5.3 Followers Collection.
|
||||||
|
|
||||||
#### 4.1.5 discoverable
|
##### publicKey
|
||||||
Indicates whether the person wishes to be discoverable via recommendations or listings of active accounts.
|
|
||||||
|
|
||||||
Implementations *MAY* provide the following properties:
|
|
||||||
|
|
||||||
#### 4.1.6 liked
|
|
||||||
A link to an [ActivityStreams collection](https://www.w3.org/TR/activitystreams-core/#collections) of objects this actor has liked; see section 5.5 Liked Collection.
|
|
||||||
|
|
||||||
#### 4.1.7 manuallyApprovesFollowers
|
|
||||||
If true then followers for this account require permission to be granted. This can be an effective anti-spam or anti-harassment feature.
|
|
||||||
|
|
||||||
#### 4.1.8 publicKey
|
|
||||||
Describes the [http header signature](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-07) public key for this account. This can be used by other accounts on the same or other federated servers to validate the authenticity of received posts.
|
Describes the [http header signature](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-07) public key for this account. This can be used by other accounts on the same or other federated servers to validate the authenticity of received posts.
|
||||||
|
|
||||||
#### 4.1.9 published
|
##### preferredUsername
|
||||||
|
A short username which may be used to refer to the actor, with no uniqueness guarantees.
|
||||||
|
|
||||||
|
#### 4.1.2 Implementations *MAY* provide the following properties:
|
||||||
|
|
||||||
|
##### discoverable
|
||||||
|
Indicates whether the person wishes to be discoverable via recommendations or listings of active accounts.
|
||||||
|
|
||||||
|
##### liked
|
||||||
|
A link to an [ActivityStreams collection](https://www.w3.org/TR/activitystreams-core/#collections) of objects this actor has liked; see section 5.5 Liked Collection.
|
||||||
|
|
||||||
|
##### manuallyApprovesFollowers
|
||||||
|
If true then followers for this account require permission to be granted. This can be an effective anti-spam or anti-harassment feature.
|
||||||
|
|
||||||
|
##### published
|
||||||
This is a timestamp for when the account was first created, and is used to show a joined date on profile screens.
|
This is a timestamp for when the account was first created, and is used to show a joined date on profile screens.
|
||||||
|
|
||||||
#### 4.1.10 updated
|
##### updated
|
||||||
A timestamp for when this actor was last changed. This can be used by followers to update their actor caches.
|
A timestamp for when this actor was last changed. This can be used by followers to update their actor caches.
|
||||||
|
|
||||||
|
##### streams
|
||||||
|
A list of supplementary Collections which may be of interest.
|
||||||
|
|
||||||
|
##### endpoints
|
||||||
|
A json object which maps additional (typically server/domain-wide) endpoints which may be useful either for this actor or someone referencing this actor. This mapping may be nested inside the actor document as the value or may be a link to a JSON-LD document with these properties.
|
||||||
|
|
||||||
|
The `endpoints` mapping *MAY* include the following properties:
|
||||||
|
|
||||||
|
###### *proxyUrl*
|
||||||
|
Endpoint URI so this actor's clients may access remote ActivityStreams objects which require authentication to access. To use this endpoint, the client posts an `x-www-form-urlencoded` `id` parameter with the value being the `id` of the requested ActivityStreams object.
|
||||||
|
|
||||||
|
###### *oauthAuthorizationEndpoint*
|
||||||
|
If OAuth 2.0 bearer tokens [RFC6749](https://datatracker.ietf.org/doc/html/rfc6749) [RFC6750](https://datatracker.ietf.org/doc/html/rfc6750) are being used for authenticating client to server interactions, this endpoint specifies a URI at which a browser-authenticated user may obtain a new authorization grant.
|
||||||
|
|
||||||
|
###### *oauthTokenEndpoint*
|
||||||
|
If OAuth 2.0 bearer tokens [RFC6749](https://datatracker.ietf.org/doc/html/rfc6749) [RFC6750](https://datatracker.ietf.org/doc/html/rfc6750) are being used for authenticating client to server interactions, this endpoint specifies a URI at which a client may acquire an access token.
|
||||||
|
|
||||||
|
###### *provideClientKey*
|
||||||
|
If Linked Data Signatures and HTTP Signatures are being used for authentication and authorization, this endpoint specifies a URI at which browser-authenticated users may authorize a client's public key for client to server interactions.
|
||||||
|
|
||||||
|
###### *signClientKey*
|
||||||
|
If Linked Data Signatures and HTTP Signatures are being used for authentication and authorization, this endpoint specifies a URI at which a client key may be signed by the actor's key for a time window to act on behalf of the actor in interacting with foreign servers.
|
||||||
|
|
||||||
|
###### *sharedInbox*
|
||||||
|
An optional endpoint used for wide delivery of publicly addressed activities and activities sent to followers. `sharedInbox` endpoints *SHOULD* also be publicly readable `OrderedCollection` objects containing objects addressed to the Public special collection. Reading from the `sharedInbox` endpoint *MUST NOT* present objects which are not addressed to the `Public` endpoint.
|
||||||
|
|
||||||
|
##### url
|
||||||
|
A link to the actor's "profile web page", if not equal to the value of `id`.
|
||||||
|
|
||||||
|
##### name
|
||||||
|
The preferred "nickname" or "display name" of the actor.
|
||||||
|
|
||||||
|
##### summary
|
||||||
|
A quick summary or biography by the user about themselves.
|
||||||
|
|
||||||
|
##### featured
|
||||||
|
Link to an [ActivityStreams collection](https://www.w3.org/TR/activitystreams-core/#collections) containing "pinned" posts appearing on the account profile screen. Such posts are typically used to provide more information about the account, beyond the profile summary.
|
||||||
|
|
||||||
|
##### featuredTags
|
||||||
|
Link to an [ActivityStreams collection](https://www.w3.org/TR/activitystreams-core/#collections) containing tag objects representing hashtags. This is used to improve discoverability.
|
||||||
|
|
||||||
|
For example, Alyssa likes reading and so she pins a post containing hashtags for her favorite books to her profile. The post appears within the `featured` collection of her `actor` and the hashtags within the post appear within `featuredTags`. When searching the hashtag for a particular book, Misha discovers Alyssa's account and decides to send a follow request based upon their mutual interest.
|
||||||
|
|
||||||
|
##### icon
|
||||||
|
Describes an image which represents the user's profile picture (this may be a thumbnail).
|
||||||
|
|
||||||
|
##### image
|
||||||
|
Describes the profile page background banner for this person.
|
||||||
|
|
||||||
### Example 9
|
### Example 9
|
||||||
``` json
|
``` json
|
||||||
{
|
{
|
||||||
|
@ -464,68 +519,6 @@ A timestamp for when this actor was last changed. This can be used by followers
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Implementations *MAY*, in addition, provide the following properties:
|
|
||||||
|
|
||||||
#### 4.1.11 streams
|
|
||||||
A list of supplementary Collections which may be of interest.
|
|
||||||
|
|
||||||
#### 4.1.12 preferredUsername
|
|
||||||
A short username which may be used to refer to the actor, with no uniqueness guarantees.
|
|
||||||
|
|
||||||
#### 4.1.13 endpoints
|
|
||||||
A json object which maps additional (typically server/domain-wide) endpoints which may be useful either for this actor or someone referencing this actor. This mapping may be nested inside the actor document as the value or may be a link to a JSON-LD document with these properties.
|
|
||||||
|
|
||||||
The `endpoints` mapping *MAY* include the following properties:
|
|
||||||
|
|
||||||
**proxyUrl**
|
|
||||||
Endpoint URI so this actor's clients may access remote ActivityStreams objects which require authentication to access. To use this endpoint, the client posts an `x-www-form-urlencoded` `id` parameter with the value being the `id` of the requested ActivityStreams object.
|
|
||||||
|
|
||||||
**oauthAuthorizationEndpoint**
|
|
||||||
If OAuth 2.0 bearer tokens [RFC6749](https://datatracker.ietf.org/doc/html/rfc6749) [RFC6750](https://datatracker.ietf.org/doc/html/rfc6750) are being used for authenticating client to server interactions, this endpoint specifies a URI at which a browser-authenticated user may obtain a new authorization grant.
|
|
||||||
|
|
||||||
**oauthTokenEndpoint**
|
|
||||||
If OAuth 2.0 bearer tokens [RFC6749](https://datatracker.ietf.org/doc/html/rfc6749) [RFC6750](https://datatracker.ietf.org/doc/html/rfc6750) are being used for authenticating client to server interactions, this endpoint specifies a URI at which a client may acquire an access token.
|
|
||||||
|
|
||||||
**provideClientKey**
|
|
||||||
If Linked Data Signatures and HTTP Signatures are being used for authentication and authorization, this endpoint specifies a URI at which browser-authenticated users may authorize a client's public key for client to server interactions.
|
|
||||||
|
|
||||||
**signClientKey**
|
|
||||||
If Linked Data Signatures and HTTP Signatures are being used for authentication and authorization, this endpoint specifies a URI at which a client key may be signed by the actor's key for a time window to act on behalf of the actor in interacting with foreign servers.
|
|
||||||
|
|
||||||
**sharedInbox**
|
|
||||||
An optional endpoint used for wide delivery of publicly addressed activities and activities sent to followers. `sharedInbox` endpoints *SHOULD* also be publicly readable `OrderedCollection` objects containing objects addressed to the Public special collection. Reading from the `sharedInbox` endpoint *MUST NOT* present objects which are not addressed to the `Public` endpoint.
|
|
||||||
|
|
||||||
**Note**
|
|
||||||
|
|
||||||
As the upstream vocabulary for ActivityPub, any applicable [ActivityStreams](https://www.w3.org/TR/activitystreams-core) property may be used on ActivityPub Actors. Some ActivityStreams properties are particularly worth highlighting to demonstrate how they are used in ActivityPub implementations.
|
|
||||||
|
|
||||||
#### 4.1.14 url
|
|
||||||
A link to the actor's "profile web page", if not equal to the value of `id`.
|
|
||||||
|
|
||||||
#### 4.1.15 name
|
|
||||||
The preferred "nickname" or "display name" of the actor.
|
|
||||||
|
|
||||||
#### 4.1.16 summary
|
|
||||||
A quick summary or biography by the user about themselves.
|
|
||||||
|
|
||||||
**Note**
|
|
||||||
|
|
||||||
Properties containing natural language values, such as `name`, `preferredUsername`, or `summary`, make use of [natural language support defined in ActivityStreams](https://www.w3.org/TR/activitystreams-core/#naturalLanguageValues).
|
|
||||||
|
|
||||||
#### 4.1.17 featured
|
|
||||||
Link to an [ActivityStreams collection](https://www.w3.org/TR/activitystreams-core/#collections) containing "pinned" posts appearing on the account profile screen. Such posts are typically used to provide more information about the account, beyond the profile summary.
|
|
||||||
|
|
||||||
#### 4.1.18 featuredTags
|
|
||||||
Link to an [ActivityStreams collection](https://www.w3.org/TR/activitystreams-core/#collections) containing tag objects representing hashtags. This is used to improve discoverability.
|
|
||||||
|
|
||||||
For example, Alyssa likes reading and so she pins a post containing hashtags for her favorite books to her profile. The post appears within the `featured` collection of her `actor` and the hashtags within the post appear within `featuredTags`. When searching the hashtag for a particular book, Misha discovers Alyssa's account and decides to send a follow request based upon their mutual interest.
|
|
||||||
|
|
||||||
#### 4.1.19 icon
|
|
||||||
Describes an image which represents the user's profile picture (this may be a thumbnail).
|
|
||||||
|
|
||||||
#### 4.1.20 image
|
|
||||||
Describes the profile page background banner for this person.
|
|
||||||
|
|
||||||
## 5. Collections
|
## 5. Collections
|
||||||
ActivityStreams defines the collection concept; ActivityPub defines several collections with special behavior. Note that ActivityPub makes use of [ActivityStreams paging](https://www.w3.org/TR/activitystreams-core/#paging) to traverse large sets of objects.
|
ActivityStreams defines the collection concept; ActivityPub defines several collections with special behavior. Note that ActivityPub makes use of [ActivityStreams paging](https://www.w3.org/TR/activitystreams-core/#paging) to traverse large sets of objects.
|
||||||
|
|
||||||
|
@ -713,7 +706,7 @@ Any `to`, `bto`, `cc`, `bcc`, and `audience` properties specified on the object
|
||||||
"type": "Note",
|
"type": "Note",
|
||||||
"content": "This is a note",
|
"content": "This is a note",
|
||||||
"published": "2015-02-10T15:04:55Z",
|
"published": "2015-02-10T15:04:55Z",
|
||||||
"to": ["https://example.org/@john/"],
|
"to": ["https://example.org/@john"],
|
||||||
"cc": ["https://example.com/@erik/followers",
|
"cc": ["https://example.com/@erik/followers",
|
||||||
"https://www.w3.org/ns/activitystreams#Public"]
|
"https://www.w3.org/ns/activitystreams#Public"]
|
||||||
}
|
}
|
||||||
|
@ -734,12 +727,12 @@ The above example could be converted to this:
|
||||||
"attributedTo": "https://example.net/users/mallory",
|
"attributedTo": "https://example.net/users/mallory",
|
||||||
"content": "This is a note",
|
"content": "This is a note",
|
||||||
"published": "2015-02-10T15:04:55Z",
|
"published": "2015-02-10T15:04:55Z",
|
||||||
"to": ["https://example.org/@john/"],
|
"to": ["https://example.org/@john"],
|
||||||
"cc": ["https://example.com/@erik/followers",
|
"cc": ["https://example.com/@erik/followers",
|
||||||
"https://www.w3.org/ns/activitystreams#Public"]
|
"https://www.w3.org/ns/activitystreams#Public"]
|
||||||
},
|
},
|
||||||
"published": "2015-02-10T15:04:55Z",
|
"published": "2015-02-10T15:04:55Z",
|
||||||
"to": ["https://example.org/@john/"],
|
"to": ["https://example.org/@john"],
|
||||||
"cc": ["https://example.com/@erik/followers",
|
"cc": ["https://example.com/@erik/followers",
|
||||||
"https://www.w3.org/ns/activitystreams#Public"]
|
"https://www.w3.org/ns/activitystreams#Public"]
|
||||||
}
|
}
|
||||||
|
@ -1155,9 +1148,26 @@ Servers should not trust client submitted content, and federated servers also sh
|
||||||
|
|
||||||
Servers should be careful to verify that new content is really posted by the actor that claims to be posting it, and that the actor has permission to update the resources it claims to. See also section 3. Objects Authentication and Authorization.
|
Servers should be careful to verify that new content is really posted by the actor that claims to be posting it, and that the actor has permission to update the resources it claims to. See also section 3. Objects Authentication and Authorization.
|
||||||
|
|
||||||
|
#### B.2.1 HTTP Signature
|
||||||
|
|
||||||
Verification of incoming posts SHOULD occur via a `http header signature` check. Currently, [draft 07 of the http signatures RFC](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-07) has become the *de facto* standard, although later versions MAY be implemented provided that sufficient support exists between federated servers.
|
Verification of incoming posts SHOULD occur via a `http header signature` check. Currently, [draft 07 of the http signatures RFC](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-07) has become the *de facto* standard, although later versions MAY be implemented provided that sufficient support exists between federated servers.
|
||||||
|
|
||||||
In addition, to allow for relaying of posts [linked data signatures](https://w3c-ccg.github.io/data-integrity-spec) MAY be used. This can allow posts to be verified as authentic even if they have passed through intermediate servers. An incoming post SHOULD be considered valid if its `http header signature` fails but an attached `linked data signature` passes.
|
A typical http signature created by Alyssa's server on an outgoing POST might look like the following:
|
||||||
|
|
||||||
|
``` http
|
||||||
|
Signature: keyId="https://instancedomain/users/alyssa#main-key",
|
||||||
|
algorithm="rsa-sha256",
|
||||||
|
headers="(request-target) host date digest content-type",
|
||||||
|
signature="tsZYmLJTJJJ/U+...=="
|
||||||
|
```
|
||||||
|
|
||||||
|
http signatures SHOULD include `host`, `date` and a `digest` created from the post.
|
||||||
|
|
||||||
|
The receiving server can obtain Alyssa's public key from `https://instancedomain/users/alyssa#main-key` and use it to verify the signature.
|
||||||
|
|
||||||
|
#### B.2.2 Linked Data Signature
|
||||||
|
|
||||||
|
To allow for relaying of posts [linked data signatures](https://w3c-ccg.github.io/data-integrity-spec) MAY be used. This can allow posts to be verified as authentic even if they have passed through intermediate servers. An incoming post SHOULD be considered valid if its `http header signature` fails but an attached `linked data signature` passes.
|
||||||
|
|
||||||
### B.3 Accessing localhost URIs
|
### B.3 Accessing localhost URIs
|
||||||
It is often convenient while developing to test against a process running on localhost. However, permitting requests to localhost in a production client or server instance can be dangerous. Making requests to URIs on localhost which do not require authorization may unintentionally access or modify resources assumed to be protected to be usable by localhost-only.
|
It is often convenient while developing to test against a process running on localhost. However, permitting requests to localhost in a production client or server instance can be dangerous. Making requests to URIs on localhost which do not require authorization may unintentionally access or modify resources assumed to be protected to be usable by localhost-only.
|
||||||
|
|
Loading…
Reference in New Issue