Okay/Spec: Difference between revisions
No edit summary |
|||
| Line 11: | Line 11: | ||
color: var(--colour-weezer-700); | color: var(--colour-weezer-700); | ||
} | } | ||
.must { color: var(--colour-bubblegum-700); font-weight: bold; } | |||
.mustnt { color: var(--colour-aubergine-700); font-weight: bold; } | |||
.should { color: var(--colour-orange-700); font-weight: bold; } | |||
.shouldnt { color: var(--colour-weezer-700); font-weight: bold; } | |||
.may { color: var(--colour-ectoplasm-700); font-weight: bold; } | |||
}}'''Okay''' dares to ask the big questions. What if group chat was hypertext? What if discord let you write arbitrary HTML? What if protocols were bad? | }}'''Okay''' dares to ask the big questions. What if group chat was hypertext? What if discord let you write arbitrary HTML? What if protocols were bad? | ||
| Line 24: | Line 31: | ||
❊ Every client is authenticated with a TLS certificate that gets generated by the client on first use. | ❊ Every client is authenticated with a TLS certificate that gets generated by the client on first use. | ||
== conventions == | |||
The key words "<span class="must">must</span>", "<span class="mustnt">must not</span>", "<span class="must">required</span>", "<span class="must">shall</span>", "<span class="mustnt>shall not</span>", "<span class="should">should</span>", "<span class="shouldnt">should not</span>", "<span class="should">recommended</span>", "<span class="may">may</span>", and "<span class="may">optional</span>" in this document are to be interpreted as described in [https://datatracker.ietf.org/doc/bcp14/| BCP14], although we use bold colourful text instead of capitals (so it doesn't look like we're yelling at you. this is a relaxed and cordial protocol specification). | |||
== todo list == | == todo list == | ||
| Line 37: | Line 48: | ||
✻ The client issues a GET request to the URI and examines the response; | ✻ The client issues a GET request to the URI and examines the response; | ||
✻ If the response meets all the discovery requirements, it generates a new certificate and registers itself with the server’s registration endpoint; | ✻ If the response meets all the [[Okay#discovery|discovery requirements]], it generates a new certificate and registers itself with the server’s registration endpoint; | ||
✻ Once everyone’s happy, the client can begin posting messages to rooms. | ✻ Once everyone’s happy, the client can begin posting messages to rooms. | ||
== servers == | |||
== discovery == | == discovery == | ||
| Line 86: | Line 99: | ||
== initiation == | == initiation == | ||
A client must register itself with a server before it can send messages to rooms. | |||
== the directory == | == the directory == | ||
| Line 94: | Line 107: | ||
Here's an example of what a room directory might look like: | Here's an example of what a room directory might look like: | ||
<syntaxhighlight lang="html"> | <syntaxhighlight lang="html"><main class="ok-rooms"> | ||
<main class="ok-rooms"> | |||
<h1>Rooms on This Server</h1> | <h1>Rooms on This Server</h1> | ||
<ul> | <ul> | ||
| Line 101: | Line 113: | ||
<li><a href="/rooms/evil" class="ok-room">Evildoing Room (evil)</a></li> | <li><a href="/rooms/evil" class="ok-room">Evildoing Room (evil)</a></li> | ||
</ul> | </ul> | ||
</main> | </main></syntaxhighlight> | ||
</syntaxhighlight> | |||
=== sections === | |||
== rooms == | == rooms == | ||
== messages == | == messages == | ||
== profiles == | == profiles == | ||