Skip to content

Commit

Permalink
Implementation Guidelines: Adapt URLs
Browse files Browse the repository at this point in the history
  • Loading branch information
cal0pteryx committed Mar 24, 2024
1 parent 232c07b commit c840039
Show file tree
Hide file tree
Showing 8 changed files with 69 additions and 75 deletions.
6 changes: 2 additions & 4 deletions content/implementation-guidelines/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ layout: single
## Overview

**Modern XMPP** is an independent project launched to improve the quality of user-to-user messaging applications
that use XMPP. [XMPP](https://xmpp.org/) is a mature open standard for internet messaging. If you are reading
that use XMPP. [XMPP](/) is a mature open standard for internet messaging. If you are reading
this, you have probably heard of it.

We are developing a handful of simple documents aimed at people who wish to build on top of XMPP. The recommendations are derived from healthy discussions between developers from multiple XMPP projects and other members of the XMPP community.
Expand All @@ -22,11 +22,9 @@ and thus make it possible to identify and weed out software that falls behind th

## Current status

It is early days. We are still building the foundations of what will become the initial set of documents. Nevertheless, we already have a bunch of stuff documented that developers of XMPP software (both new and experienced) will find useful. This includes [design guidelines](client/design.md) and lower-level [protocol implementation recommendations](client/protocol.md).
It is early days. We are still building the foundations of what will become the initial set of documents. Nevertheless, we already have a bunch of stuff documented that developers of XMPP software (both new and experienced) will find useful. This includes [design guidelines](/implementation-guidelines/design) and lower-level [protocol implementation recommendations](/implementation-guidelines/protocol).

If you're interested in joining us, our primary discussion venue is our *channel* which can be reached at:

- XMPP: [modernxmpp@rooms.modernxmpp.org](xmpp:modernxmpp@rooms.modernxmpp.org?join)
- Web: [chat.modernxmpp.org](https://chat.modernxmpp.org/)

Contributions to the docs can be made through Github [modernxmpp/modernxmpp](https://github.com/modernxmpp/modernxmpp).
18 changes: 7 additions & 11 deletions content/implementation-guidelines/design.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,7 @@
---
Title: Design Guidelines
Title: Client Design Guidelines
---

Title:

# Client design guidelines

This document lays out a set of guidelines for designing Modern XMPP clients. For contributions,
please [open an issue or pull request](https://github.com/modernxmpp/modernxmpp) at Github for discussion.

Expand Down Expand Up @@ -41,16 +37,16 @@ Support for these options is OPTIONAL, but **not** recommended. They are only ne
| Connect port | The network port to connect to |
| TLS Mode[^tls-mode] | Multiple choice: "STARTTLS" or "Direct TLS" |

Both of the above should be automatically discovered from DNS, according to the [rules in RFC 6120](https://xmpp.org/rfcs/rfc6120.html#tcp-resolution).
Clients that support other connection mechanisms, such as BOSH, SHOULD also implement [XEP-0156](https://xmpp.org/extensions/xep-0156.html).
Both of the above should be automatically discovered from DNS, according to the [rules in RFC 6120](/rfcs/rfc6120.html#tcp-resolution).
Clients that support other connection mechanisms, such as BOSH, SHOULD also implement [XEP-0156](/extensions/xep-0156.html).

### Deprecated options

Support for these options is NOT RECOMMENDED.

| Option | Description | Notes |
|:-------------|:-----------------------------------------|:--------|
| Resource | The resource to request from the server | see [Resource generation](protocol.md#resource-generation) |
| Resource | The resource to request from the server | see [Resource generation](/implementation-guidelines/protocol#resource-generation) |
| Priority | The priority to include in presence | 0 |

## User status
Expand Down Expand Up @@ -133,7 +129,7 @@ Support for multiple accounts is OPTIONAL.

## Group chat

You can find more details about [group chats here](groupchat.md).
You can find more details about [group chats here](/implementation-guidelines/groupchat).

## Documentation

Expand Down Expand Up @@ -168,7 +164,7 @@ Address book
: Platform-dependent. If the application is somehow linked to the user's address book and is able to access a contact's information there.

User nickname
: A nickname published by the sender in PEP per [XEP-0172](https://xmpp.org/extensions/xep-0172.html).
: A nickname published by the sender in PEP per [XEP-0172](/extensions/xep-0172.html).

Resource
: The resource of the sending JID.
Expand Down Expand Up @@ -203,7 +199,7 @@ A client may want to associate a color with a user. Example use cases for this i
- Dummy avatars in contexts where an avatar cannot be or has not yet been retrieved
- Coloring the user name in a conversation log (be aware that this needs to be done very carefully to be accessible!)

To generate a color for a user, the algorithm described in [XEP-0392](https://xmpp.org/extensions/xep-0392.html) MUST be used.
To generate a color for a user, the algorithm described in [XEP-0392](/extensions/xep-0392.html) MUST be used.

### Generator input based on context

Expand Down
24 changes: 12 additions & 12 deletions content/implementation-guidelines/groupchat.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,9 +20,9 @@ To detect if a multi-user chat is a *group chat* or a *channel*
| Publicly listed | muc#roomconfig_publicroom | No (3) | muc_hidden | Yes | muc_public |
| PMs | muc#roomconfig_allowpm | No (3) | muc#roomconfig_allowpm to `none` | Yes | muc#roomconfig_allowpm to `anyone` |

(1) As defined in [XEP-0045: Multi-User Chat - 16.5.3](https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owner)
(1) As defined in [XEP-0045: Multi-User Chat - 16.5.3](/extensions/xep-0045.html#registrar-formtype-owner)

(2) As defined in [XEP-0045: Multi-User Chat - 16.3](https://xmpp.org/extensions/xep-0045.html#registrar-features)
(2) As defined in [XEP-0045: Multi-User Chat - 16.3](/extensions/xep-0045.html#registrar-features)

(3) Immutable for *group chats*.

Expand All @@ -31,7 +31,7 @@ Options marked `(3) Immutable` should be used when creating group chats, and als
#### About PMs

While it is possible to entirely prevent PMs from being sent with
[`muc#roomconfig_allowpm`](https://xmpp.org/extensions/xep-0045.html#privatemessage),
[`muc#roomconfig_allowpm`](/extensions/xep-0045.html#privatemessage),
clients should prefer using JIDs when `muc#roomconfig_whois` is set to `anyone`.

In channels, if the initiating client has access to revealed JIDs (with
Expand Down Expand Up @@ -73,12 +73,12 @@ Bookmark
: If the chat is present in the user's bookmarks and has a nickname present (as the resource).

Reserved name
: A chat [may be queried](https://xmpp.org/extensions/xep-0045.html#reservednick) to fetch the
: A chat [may be queried](/extensions/xep-0045.html#reservednick) to fetch the
name that is registered by the user for that chat.

User nickname (PEP)
: The name stored in the user's account according to
[XEP-0172](https://xmpp.org/extensions/xep-0172.html#manage).
[XEP-0172](/extensions/xep-0172.html#manage).

User nickname (vCard)
: The name stored in the user's vCard as `NICKNAME`.
Expand All @@ -91,21 +91,21 @@ JID username

### Other user's names

The display of other user's names is covered in the [general UI recommendations](design.md#names).
The display of other user's names is covered in the [general UI recommendations](/implementation-guidelines/design#names).

## Bookmarks

Figuring out which group chats to join is the client’s job. For that it
should store the list of group chats to rejoin automatically on the
server, named bookmarks. Three possible protocols exist for this:

- [XEP-0402](https://xmpp.org/extensions/xep-0402.html) which is the
- [XEP-0402](/extensions/xep-0402.html) which is the
current preferred method
- [XEP-0048 1.1](https://xmpp.org/extensions/xep-0048.html), recently
- [XEP-0048 1.1](/extensions/xep-0048.html), recently
deprecated but still in use by some clients
- [XEP-0048 1.0](https://xmpp.org/extensions/attic/xep-0048-1.0.html),
- [XEP-0048 1.0](/extensions/attic/xep-0048-1.0.html),
in wide use, based on
[XEP-0049](https://xmpp.org/extensions/xep-0049.html)
[XEP-0049](/extensions/xep-0049.html)

In order to see the same set of bookmarks as every other client the
user might be using, it is recommended to implement **XEP-0048 1.0** first
Expand All @@ -115,7 +115,7 @@ This legacy protocol however doesn’t support notifications when the bookmarks
change due to another client or the server. To avoid this issue, a modern client
should also implement **XEP-0402** ("PEP Native Bookmarks"), but use it *only* if the account
advertises 'urn:xmpp:bookmarks:1#compat' (as defined in [XEP-0402 paragraph 5.3
Compatibility](https://xmpp.org/extensions/xep-0402.html#compatibility)).
Compatibility](/extensions/xep-0402.html#compatibility)).

Implementing XEP-0048 1.1 is not recommended in modern clients.

Expand All @@ -133,7 +133,7 @@ Clients must always use real JIDs for messaging privately within a *group chat*

<!-- Footnotes -->

[^rationale-gc]: Rationale [group chats](/rationale#group-chats)
[^rationale-gc]: Rationale [group chats](/implementation-guidelines/rationale#group-chats)
[^local-nickname]: To avoid requiring the user to configure a nickname manually on each device, shared cross-device stores such as PEP and vCard should be preferred.
[^pm-realjid]: If real JIDs are known to all participants, it is preferable to use that for private communication to avoid confusion. Through-MUC PMs have the following disadvantages:

Expand Down
6 changes: 3 additions & 3 deletions content/implementation-guidelines/invites.md
Original file line number Diff line number Diff line change
Expand Up @@ -116,6 +116,6 @@ If possible, platform detection should be used to highlight download links relev

If the detected platform is a desktop environment, consider also adding a QR code for easy transmission to a user's mobile device.

[XEP-0401]: https://xmpp.org/extensions/xep-0401.html "Ad-hoc Account Invitation Generation"
[XEP-0445]: https://xmpp.org/extensions/xep-0445.html "Pre-Authenticated In-Band Registration"
[XEP-0379]: https://xmpp.org/extensions/xep-0379.html "Pre-Authenticated Roster Subscription"
[XEP-0401]: /extensions/xep-0401.html "Ad-hoc Account Invitation Generation"
[XEP-0445]: /extensions/xep-0445.html "Pre-Authenticated In-Band Registration"
[XEP-0379]: /extensions/xep-0379.html "Pre-Authenticated Roster Subscription"
Loading

0 comments on commit c840039

Please sign in to comment.