Move glossary to section #1

docs/Protocol Specifications/core.md

@@ -77,26 +77,9 @@ which can operate with other polyproto implementations.
 
 ## 1. Terminology used in this document
 
-In addition to the terminology found in the glossary located at the end of this document, the
-following terminology is used throughout this document:
+The following terminology is used throughout this document:
 
-<a id="terminology-message"/>
-
-- **Message, Messages**: In the context of this protocol specification, a **message** is any piece
-  of data sent by a client that is intended to be identifiable as being sent by a specific actor.
-  To qualify as a "message", this piece of data must also, at any point in time, and also if only
-  briefly, be visible to other users or to the unauthenticated public. Examples of things that would
-  qualify as messages include:
-
-  - A message sent to another actor in a chat application
-  - A post on a social media platform
-  - A "like" interaction on a social media platform
-  - Reaction emojis in Discord-like chat applications
-  - Group join or leave messages
-  - Reporting a post or actor, if the report is not anonymous
-
-Terminology not specified in this section or in the glossary has been defined somewhere else in this
-document.
+--8<-- "snippets/glossary.md"
 
 ## 2. Trust model
 
@@ -217,7 +200,7 @@ different server or join the Guilds of other servers.
 
 Identity certificates defined in sections [#6. Cryptography and ID-Certs](#6-cryptography-and-id-certs)
 and [#6.1 Home server signed certificates for public client identity keys (ID-Cert)](#61-home-server-signed-certificates-for-public-client-identity-keys-id-cert)
-are employed to sign [messages](#terminology-message) that the actor sends to other servers.
+are employed to sign messages that the actor sends to other servers.
 
 !!! note "Using one identity for several polyproto implementations"
 
@@ -386,7 +369,7 @@ A CSR in the context of polyproto will be referred to as an ID-CSR. ID-CSRs are
 
 All ID-Certs are valid X.509 v3 certificates. However, not all X.509 v3 certificates are valid ID-Certs.
 
-ID-Certs form the basis of [message](#terminology-message) signing and verification in polyproto.
+ID-Certs form the basis of message signing and verification in polyproto.
 They are used to verify the identity of a client, and to verify the integrity of messages sent by a
 client.
 
@@ -499,7 +482,7 @@ server public identity key caching, but no home server issued identity key certi
 
 !!! example "Potential misuse scenario"
 
-    A malicious foreign server B can fake a [message](#terminology-message) from Alice
+    A malicious foreign server B can fake a message from Alice
     (Home server: Server A) to Bob (Home Server: Server B), by generating a new identity key pair
     and using it to sign the malicious message. The foreign server then sends that message to Bob,
     who will then request Alice's public identity key from Server B, who will then send Bob the
@@ -527,7 +510,7 @@ Rotating keys is done by using an API route, which requires authorization.
     and how this risk is mitigated is up to concrete implementations.
 
 Home servers must keep track of the ID-Certs of all users (and their clients) registered on them,
-and must offer a clients' ID-Cert for a given timestamp on request. This is to ensure [messages](#terminology-message)
+and must offer a clients' ID-Cert for a given timestamp on request. This is to ensure messages
 sent by users, even ones sent a long time ago, can be verified by other servers and their users.
 This is because the public key of an actor likely changes over time and users must sign all messages
 they send to servers. Likewise, a client should also keep all of its own ID-Certs stored
@@ -597,7 +580,7 @@ must revoke the session associated with the revoked ID-Cert. Revoking an ID-Cert
 
 As briefly mentioned section [#4](#4-federated-identity), users must hold on to an identity key pair
 at all times. This key pair is used to represent an actor's identity and to verify
-[message](#terminology-message) integrity, by having an actor sign all messages they send with their
+message integrity, by having an actor sign all messages they send with their
 private identity key. The key pair is generated by the actor. An actor-generated identity key
 certificate signing request (CSR) is sent to the actor's home server when first connecting to the
 server with a new session, or when rotating keys. The key is stored in the client's local storage.
@@ -608,7 +591,7 @@ information about the certificate.
 
 #### 6.2.1 Message verification
 
-To ensure [message](#terminology-message) integrity through signing, clients and servers must verify
+To ensure message integrity through signing, clients and servers must verify
 message signatures. This involves cross-checking the message signature against the sender's
 ID-Cert and the senders' home server's ID-Cert, while also confirming the validity of the
 ID-Cert attached to the message and ensuring its public key matches the sender's.
@@ -787,7 +770,7 @@ The APIs for managing encrypted private identity keys are documented in the API
 ## 7. Migrations
 
 polyproto empowers the end-user by defining straightforward mechanisms to change their home server
-while preserving their identity, moving [messages](#terminology-message) to another server, or both.
+while preserving their identity, moving messages to another server, or both.
 
 Identity migration allows actors to transparently re-assign ownership of their identity and messages
 to a new identity. This allows users to switch home servers while not losing ownership of messages
@@ -805,7 +788,7 @@ a sensitive action.
 Changing the publicly visible ownership of actor data requires the chain of trust to be maintained.
 If an "old" account wants to change the publicly visible ownership of its data, the "old"
 account must prove that it possesses the private keys that were used to
-sign the [messages](#terminology-message). This is done by signing a challenge string with the private
+sign the messages. This is done by signing a challenge string with the private
 keys. If the server verifies the challenge, it authorizes the new account to re-sign the old
 account's messages signed with the verified key. Instead of overwriting the message, a new message variant
 with the new signature is created, preserving the old message.
@@ -827,7 +810,7 @@ re-signed.
 
 ### 7.2 Reassigning ownership
 
-Transferring [message](#terminology-message) ownership from an old to a new account, known as
+Transferring message ownership from an old to a new account, known as
 re-signing messages, necessitates coordination between the two accounts, initiated by the
 old account. To start, the old account sends an API request containing the new account's
 federation ID to the server where messages should be re-signed. The server responds with all
@@ -974,7 +957,7 @@ is implemented is up to the concrete implementation.
 ## 8. Protocol extensions (P2 extensions)
 
 polyproto leaves room for extensions, outsourcing concepts such as concrete
-[message](#terminology-message) types to protocol extensions. This allows for a more flexible
+message types to protocol extensions. This allows for a more flexible
 core protocol, which can be adapted to a wide variety of use cases. The following sections
 define:
 
@@ -1182,10 +1165,6 @@ not change the key-value pair.
 Changing a primary service provider entry is considered a sensitive action and should
 require a second factor of authentication.
 
-[Messages](#terminology-message) do not get moved or re-signed when changing the primary
+messages do not get moved or re-signed when changing the primary
 service provider for a given service. If an actor wants to move their messages to the new primary
 service provider, they must request a [migration](#7-migrations).
-
----
-
---8<-- "snippets/glossary.md"