mirror of
https://github.com/matrix-construct/construct
synced 2024-10-31 10:58:54 +01:00
32 lines
2.1 KiB
Markdown
32 lines
2.1 KiB
Markdown
## IRCd (Charybdis) Client
|
|
|
|
This client provides a fully functioning Matrix chat experience in addition to driving the server
|
|
administration functions of IRCd. This client should not de-prioritize the chat client features
|
|
in favor of focusing on server admin: it is testbed for any new features and experimentation
|
|
conducted with IRCd.
|
|
|
|
The "Matrix" chat protocol is an extensible and recursively structured approach to the next
|
|
evolution of the Internet Relay Chat (IRC) protocol. Though not syntactically backwards-compatible
|
|
with the IRC protocol, it can be easily translated as a superset. Similar to IRC protocol's
|
|
origins, it wisely leverages technologies in vogue for its day to aid the virility of
|
|
implementations.
|
|
|
|
As the 3rd major-version evolution of IRC, we refer to IRC^3 or "IRC cubed" or "Matrix protocol"
|
|
as all the same entity.
|
|
|
|
Matrix protocol achieves what the last IRC protocol could not, among other things: a
|
|
consolidated internetworked federation of servers/networks that can all speak to each other.
|
|
Authority in the federation is partitioned by domain-names and uses the standard URL system.
|
|
|
|
IRCv2 is deadlocked in part because of the ecosystem of servers and clients are old; they push
|
|
the limits of cross-platform compatibility to deliver the best graphical or terminal experience
|
|
from their day (and to this day!). The protocol has shallow structure; evolving it adds inelegant
|
|
complexity. There was no attempt at forward-compatibility; it is easily broken. The initiative to
|
|
propose and develop a new feature with widespread adoption is suppressed by these facts.
|
|
|
|
While the first conception of the IRC protocol in 1988 made considerations for a person typing
|
|
at a local or remote-access textual terminal, matrix makes considerations for "the web." The
|
|
protocol stands on the shoulders of JSON content transferred via HTTP requests. This choice
|
|
permits the seamless implementation of clients developed with the best choice for developing
|
|
a client in this epoch: the javascript-actuated stylized-document object in a browser -- which
|
|
is customized dynamically from the server.
|