diff --git a/.gitignore b/.gitignore
index 5ef6a52..26944c3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -39,3 +39,5 @@ yarn-error.log*
# typescript
*.tsbuildinfo
next-env.d.ts
+
+/.idea
\ No newline at end of file
diff --git a/src/app/layout.tsx b/src/app/layout.tsx
index 7b181dc..52bcc5b 100644
--- a/src/app/layout.tsx
+++ b/src/app/layout.tsx
@@ -1,6 +1,8 @@
import type { Metadata } from "next";
import { Geist, Rokkitt } from "next/font/google";
import "./globals.css";
+import NavBar from "@/components/NavBar";
+import Footer from "@/components/Footer";
const geistSans = Geist({
variable: "--font-geist",
@@ -25,9 +27,11 @@ export default function RootLayout({
return (
+
{children}
+
);
diff --git a/src/app/page.tsx b/src/app/page.tsx
index 8051d99..d56a6e7 100644
--- a/src/app/page.tsx
+++ b/src/app/page.tsx
@@ -1,25 +1,17 @@
-import NavBar from "@/components/NavBar";
-import Footer from "@/components/Footer";
import Text from "@/components/blocks/Text";
export default function Home() {
return (
-
-
-
-
- Welcome to an unofficial webpage about the Real Address Chat protocol.
- Here you can find clients, servers, and documentation on how to use
- RAC and its successor, WRAC.
-
-
- Want to add your project to Racinfo? Make a pull request on our
- official GitHub repository, and we’ll review it.
-
-
-
-
+
+
+ Welcome to an unofficial webpage about the Real Address Chat protocol.
+ Here you can find clients, servers, and documentation on how to use RAC
+ and its successor, WRAC.
+
+
+ Want to add your project to Racinfo? Make a pull request on our official
+ GitHub repository, and we’ll review it.
+
+
);
}
diff --git a/src/app/projects/page.tsx b/src/app/projects/page.tsx
index 7a89710..252de4b 100644
--- a/src/app/projects/page.tsx
+++ b/src/app/projects/page.tsx
@@ -43,13 +43,6 @@ export default function Projects() {
description: "Coming Soon™",
tags: ["Unreleased", "WRAC", "RAC", "v2"],
},
- {
- name: "oWRAC",
- authorId: "pansangg",
- projectGit: "https://github.com/pansangg/oWRAC",
- description: "An online WRAC client (works in web)",
- tags: ["Unreleased", "WRAC", "v2"],
- },
{
name: "clRAC",
externalDownload: true,
@@ -116,61 +109,55 @@ export default function Projects() {
];
return (
-
-
-
- Projects
-
- This is a curated list of projects that is related to RAC protocol.
- There is a client and server implementations of RAC. Note that some
- projects are not available on Git services and should be downloaded
- from external sources. They are marked with
- external@ text at the beginning of the author
- ID. If you want to add your project to this list, please make an issue
- on our GitHub repository.
-
- Clients
-
- Here is a grid of all available client for RAC protocol with their
- respective repository link.
-
-
- {clients.map((client) => (
-
- ))}
-
- Servers
-
- And here are the servers implementation! You can choose whatever you
- want and setup your own RAC server.
-
-
- {servers.map((server) => (
-
- ))}
-
-
-
-
+
+ Projects
+
+ This is a curated list of projects that is related to RAC protocol.
+ There is a client and server implementations of RAC. Note that some
+ projects are not available on Git services and should be downloaded from
+ external sources. They are marked with
+ external@ text at the beginning of the author
+ ID. If you want to add your project to this list, please make an issue
+ on our GitHub repository.
+
+ Clients
+
+ Here is a grid of all available client for RAC protocol with their
+ respective repository link.
+
+
+ {clients.map((client) => (
+
+ ))}
+
+ Servers
+
+ And here are the servers implementation! You can choose whatever you
+ want and setup your own RAC server.
+
+
+ {servers.map((server) => (
+
+ ))}
+
+
);
}
diff --git a/src/app/protocol/page.tsx b/src/app/protocol/page.tsx
index 6e73d90..257d5bd 100644
--- a/src/app/protocol/page.tsx
+++ b/src/app/protocol/page.tsx
@@ -1,81 +1,73 @@
-import NavBar from "@/components/NavBar";
-import Footer from "@/components/Footer";
-import Link from "next/link";
+import Link from "next/link";
import Text from "@/components/blocks/Text";
import PageTitle from "@/components/blocks/PageTitle";
import Title from "@/components/blocks/Title";
export default function Protocol() {
return (
-
-
-
- Protocol
-
- Real Address Chat is a protocol based on TCP intended for chatting,
- like IRC. It was supposed to be an “IRC killer,” but in reality, its
- implementation is poor. There’s also a community-made successor called
- WRAC. It’s basically the same as RAC, but it uses WebSockets instead
- of TCP for connections.
-
-
- If you want to experiment with or implement RAC in your client or
- server, use the documentation below to understand how it works.
-
- Articles
- Click on article down below that you want to read.
-
-
-
- Real Address Chat Protocol
-
-
- This article explains the Real Address Chat protocol and how the
- client and server interact with each other using it.
-
- Curated by @kostya-zero
-
-
-
- WebSocket Real Address Chat Protocol
-
-
- WRAC is a WebSocket-based implementation of the RAC protocol, made
- by the community. It works the same as RAC but includes some
- additions.
-
- Curated by @kostya-zero
-
-
-
- User Agents
-
-
- A community-made solution to identify clients by a unique symbol
- in front of their username.
-
- Curated by @kostya-zero
-
-
-
-
-
+
+ Protocol
+
+ Real Address Chat is a protocol based on TCP intended for chatting, like
+ IRC. It was supposed to be an “IRC killer,” but in reality, its
+ implementation is poor. There’s also a community-made successor called
+ WRAC. It’s basically the same as RAC, but it uses WebSockets instead of
+ TCP for connections.
+
+
+ If you want to experiment with or implement RAC in your client or
+ server, use the documentation below to understand how it works.
+
+ Articles
+ Click on article down below that you want to read.
+
+
+
+ Real Address Chat Protocol
+
+
+ This article explains the Real Address Chat protocol and how the
+ client and server interact with each other using it.
+
+ Curated by @kostya-zero
+
+
+
+ WebSocket Real Address Chat Protocol
+
+
+ WRAC is a WebSocket-based implementation of the RAC protocol, made
+ by the community. It works the same as RAC but includes some
+ additions.
+
+ Curated by @kostya-zero
+
+
+
+ User Agents
+
+
+ A community-made solution to identify clients by a unique symbol in
+ front of their username.
+
+ Curated by @kostya-zero
+
+
+
);
}
diff --git a/src/app/protocol/rac/page.tsx b/src/app/protocol/rac/page.tsx
index 7bc5aec..4306834 100644
--- a/src/app/protocol/rac/page.tsx
+++ b/src/app/protocol/rac/page.tsx
@@ -1,6 +1,4 @@
-import NavBar from "@/components/NavBar";
-import Footer from "@/components/Footer";
-import { ArrowLeft } from "lucide-react";
+import { ArrowLeft } from "lucide-react";
import Link from "next/link";
import {
Table,
@@ -18,189 +16,179 @@ import Code from "@/components/blocks/Code";
export default function Rac() {
return (
-
-
+
-
-
- Go Back
-
-
- Real Address Chat Protocol
-
-
- As mentioned earlier, RAC is a TCP-based protocol, so the server and
- client communicate by sending TCP packets to each other. The
- implementation is pretty simple, so don’t worry.
-
-
- All RAC servers use port 42666 by default,
- but servers that implement RACS (Real Address Chat Secure) use port{" "}
- 42667.
-
-
- Keep in mind that the RAC server closes the connection after each
- message sent from the client. In some cases, it might receive two
- packets, but it will still close the connection.
-
- Receiving messages
-
- Receiving messages from the server is implemented in an unusual way.
- There are two ways to receive messages from the server.
-
-
- But before you try to receive new messages, you need to get the total
- size of all messages. The messages are stored on the server in a
- single file, and to get new messages, you should send an offset.
-
-
- To receive the current size of the messages on the server, you need to
- send a 0x00 byte to the server. In response,
- the server will return the current size of the messages. Now, let’s
- begin receiving those messages.
-
-
- The first way is to receive all messages stored on the server. The
- client should send a 0x00 byte and then, in
- the same stream, send a 0x01 byte to the
- server. The server will respond with all messages, separated by{" "}
- \n.
-
-
- The second way is to get messages in chunks. Again, the client sends a{" "}
- 0x00 byte and then sends a{" "}
- 0x02 byte, along with the size of the
- messages it wants to receive. The number of messages to receive is
- calculated using this formula:
-
- new_received_size - last_known_size
-
- The server will send messages matching the requested size, separated
- by \n.
-
- Sending messages
-
- Sending messages in RAC is implemented simply, but with some
- interesting details. The server doesn’t identify clients or users, so
- clients have to handle that themselves. This means the client must
- send the user agent, username, and message all in one packet. For
- example:
-
- {"▲ Hello, world!"}
-
- Did you notice the ▲ symbol? This is called a
- User Agent. In this example, the message was sent by the Tower client,
- because ▲ is its respective user agent. As
- mentioned earlier, the server itself cannot identify clients, so
- clients have to identify each other using these user agents.
-
-
- Also, note that zero is wrapped inside{" "}
- {"<>"}. This approach makes parsing messages
- easier with regex. Learn more about user agents and how to create your
- own in the user agents article.
-
-
- Note that the server should store the IP address with each sent
- message. However, messages sent by clients in authorized mode should
- be ignored for this. This idea, introduced by Sugoma, means that
- clients shouldn’t be anonymous unless they’re authorized. Still, most
- clients ignore the IP address and don’t display it.
-
-
- Back to sending messages: To send a message to the server, the client
- should send a 0x01 byte, followed by the
- message in the same packet—not separately. After that, you won’t
- receive anything from the server, even if there’s an error. So your
- final message should look like this:
-
- {" Hello, everyone!"}
-
- Also, server that are implements RAC v2 allows to send messages in
- authorized mode. To send message in authorized mode, you need to send{" "}
- 0x02 and after that, separating by{" "}
- \n, send user's user name, password and
- message (do not include \n in the
- end).
-
-
- If the message was sent successfully, the server won’t send any
- response. If not, the server will send a 0x01{" "}
- byte if the user doesn’t exist, and a 0x02{" "}
- byte if the password is incorrect.
-
- Authorization
-
- Authorization is only available on servers that implement the RAC v2
- protocol, which adds an authorization system. This feature was added
- by Sugoma for people who don’t want to expose their IP address to
- everyone.
-
-
- Before sending messages in authorized mode, you need to register a
- user on the server. To do this, the client should send a{" "}
- 0x03 byte and, just like when sending
- messages, include the username and password separated by{" "}
- \n. If the user is created, the client will
- receive nothing in response. If the user already exists, the server
- will respond with a 0x01 byte.
-
- TLS Connection
-
- You can wrap your connection with TLS encryption. There’s nothing
- special about it.
-
- Special Packets
-
- Some servers can implement special packets, but most of the time they
- don’t add much functionality.
-
-
- One of them is the 0x69 byte. You can send
- this byte to the server to get technical information about it. For
- example, after sending this byte, you might receive these bytes in
- response:
-
-
-
-
- Byte
- Meaning
-
-
-
-
-
- 0x01
-
- The server supports RAC v1.0
-
-
-
- 0x02
-
- The server supports RAC v1.99
-
-
-
- 0x03
-
- The server supports RAC v2.0
-
-
-
-
- Also, right after this byte, the server will send information about
- itself, such as the server software name and its version.
-
-
-
-
+ Go Back
+
+
+ Real Address Chat Protocol
+
+
+ As mentioned earlier, RAC is a TCP-based protocol, so the server and
+ client communicate by sending TCP packets to each other. The
+ implementation is pretty simple, so don’t worry.
+
+
+ All RAC servers use port 42666 by default, but
+ servers that implement RACS (Real Address Chat Secure) use port{" "}
+ 42667.
+
+
+ Keep in mind that the RAC server closes the connection after each
+ message sent from the client. In some cases, it might receive two
+ packets, but it will still close the connection.
+
+ Receiving messages
+
+ Receiving messages from the server is implemented in an unusual way.
+ There are two ways to receive messages from the server.
+
+
+ But before you try to receive new messages, you need to get the total
+ size of all messages. The messages are stored on the server in a single
+ file, and to get new messages, you should send an offset.
+
+
+ To receive the current size of the messages on the server, you need to
+ send a 0x00 byte to the server. In response,
+ the server will return the current size of the messages. Now, let’s
+ begin receiving those messages.
+
+
+ The first way is to receive all messages stored on the server. The
+ client should send a 0x00 byte and then, in the
+ same stream, send a 0x01 byte to the server.
+ The server will respond with all messages, separated by{" "}
+ \n.
+
+
+ The second way is to get messages in chunks. Again, the client sends a{" "}
+ 0x00 byte and then sends a{" "}
+ 0x02 byte, along with the size of the messages
+ it wants to receive. The number of messages to receive is calculated
+ using this formula:
+
+ new_received_size - last_known_size
+
+ The server will send messages matching the requested size, separated by{" "}
+ \n.
+
+ Sending messages
+
+ Sending messages in RAC is implemented simply, but with some interesting
+ details. The server doesn’t identify clients or users, so clients have
+ to handle that themselves. This means the client must send the user
+ agent, username, and message all in one packet. For example:
+
+ {"▲ Hello, world!"}
+
+ Did you notice the ▲ symbol? This is called a
+ User Agent. In this example, the message was sent by the Tower client,
+ because ▲ is its respective user agent. As
+ mentioned earlier, the server itself cannot identify clients, so clients
+ have to identify each other using these user agents.
+
+
+ Also, note that zero is wrapped inside{" "}
+ {"<>"}. This approach makes parsing messages
+ easier with regex. Learn more about user agents and how to create your
+ own in the user agents article.
+
+
+ Note that the server should store the IP address with each sent message.
+ However, messages sent by clients in authorized mode should be ignored
+ for this. This idea, introduced by Sugoma, means that clients shouldn’t
+ be anonymous unless they’re authorized. Still, most clients ignore the
+ IP address and don’t display it.
+
+
+ Back to sending messages: To send a message to the server, the client
+ should send a 0x01 byte, followed by the
+ message in the same packet—not separately. After that, you won’t receive
+ anything from the server, even if there’s an error. So your final
+ message should look like this:
+
+ {" Hello, everyone!"}
+
+ Also, server that are implements RAC v2 allows to send messages in
+ authorized mode. To send message in authorized mode, you need to send{" "}
+ 0x02 and after that, separating by{" "}
+ \n, send user's user name, password and
+ message (do not include \n in the end).
+
+
+ If the message was sent successfully, the server won’t send any
+ response. If not, the server will send a 0x01{" "}
+ byte if the user doesn’t exist, and a 0x02 byte
+ if the password is incorrect.
+
+ Authorization
+
+ Authorization is only available on servers that implement the RAC v2
+ protocol, which adds an authorization system. This feature was added by
+ Sugoma for people who don’t want to expose their IP address to everyone.
+
+
+ Before sending messages in authorized mode, you need to register a user
+ on the server. To do this, the client should send a{" "}
+ 0x03 byte and, just like when sending messages,
+ include the username and password separated by{" "}
+ \n. If the user is created, the client will
+ receive nothing in response. If the user already exists, the server will
+ respond with a 0x01 byte.
+
+ TLS Connection
+
+ You can wrap your connection with TLS encryption. There’s nothing
+ special about it.
+
+ Special Packets
+
+ Some servers can implement special packets, but most of the time they
+ don’t add much functionality.
+
+
+ One of them is the 0x69 byte. You can send this
+ byte to the server to get technical information about it. For example,
+ after sending this byte, you might receive these bytes in response:
+
+
+
+
+ Byte
+ Meaning
+
+
+
+
+
+ 0x01
+
+ The server supports RAC v1.0
+
+
+
+ 0x02
+
+ The server supports RAC v1.99
+
+
+
+ 0x03
+
+ The server supports RAC v2.0
+
+
+
+
+ Also, right after this byte, the server will send information about
+ itself, such as the server software name and its version.
+
+
);
}
diff --git a/src/app/protocol/user-agents/page.tsx b/src/app/protocol/user-agents/page.tsx
index 28714d2..30ffcb9 100644
--- a/src/app/protocol/user-agents/page.tsx
+++ b/src/app/protocol/user-agents/page.tsx
@@ -1,6 +1,4 @@
-import NavBar from "@/components/NavBar";
-import Footer from "@/components/Footer";
-import { ArrowLeft } from "lucide-react";
+import { ArrowLeft } from "lucide-react";
import Link from "next/link";
import {
Table,
@@ -60,69 +58,61 @@ export default function Wrac() {
},
];
return (
-
-
+
-
-
- Go Back
-
- User Agents
-
- The RAC protocol doesn’t have any functionality to identify clients,
- so the community decided to use their own solution called{" "}
- User Agents.
-
-
- User Agents in RAC are implemented by adding an extra Unicode symbol
- as a prefix to usernames. For example, a message sent with the Tower
- client:
-
- {"▲ Hello, world!"}
-
- The ▲ symbol in front of the username
- indicates that this message was sent using the Tower client. The
- client should use regex to parse these messages and determine the
- client, username, and message.
-
-
- Known Agents
-
-
- Below is a table of known user agents with their client names and
- regular expressions. Clients can also optionally use colored usernames
- for each client. You can add your own user agent via a pull request.
-
-
-
-
- Client Name
- Regular Expression
- Color
+ Go Back
+
+ User Agents
+
+ The RAC protocol doesn’t have any functionality to identify clients, so
+ the community decided to use their own solution called{" "}
+ User Agents.
+
+
+ User Agents in RAC are implemented by adding an extra Unicode symbol as
+ a prefix to usernames. For example, a message sent with the Tower
+ client:
+
+ {"▲ Hello, world!"}
+
+ The ▲ symbol in front of the username indicates
+ that this message was sent using the Tower client. The client should use
+ regex to parse these messages and determine the client, username, and
+ message.
+
+
+ Known Agents
+
+
+ Below is a table of known user agents with their client names and
+ regular expressions. Clients can also optionally use colored usernames
+ for each client. You can add your own user agent via a pull request.
+
+
+
);
}
diff --git a/src/app/protocol/wrac/page.tsx b/src/app/protocol/wrac/page.tsx
index 2738fa4..66613c1 100644
--- a/src/app/protocol/wrac/page.tsx
+++ b/src/app/protocol/wrac/page.tsx
@@ -1,6 +1,4 @@
-import NavBar from "@/components/NavBar";
-import Footer from "@/components/Footer";
-import { ArrowLeft } from "lucide-react";
+import { ArrowLeft } from "lucide-react";
import Link from "next/link";
import Text from "@/components/blocks/Text";
import PageTitle from "@/components/blocks/PageTitle";
@@ -9,45 +7,37 @@ import InlineCode from "@/components/blocks/InlineCode";
export default function Wrac() {
return (
-
-
+
-
-
- Go Back
-
-
- WebSocket Real Address Chat Protocol
-
-
- WRAC (WebSocket Real Address Chat) is a community-made successor to
- RAC that uses WebSockets instead of TCP. It uses the same requests as
- RAC, but you should send data in binary format. Unlike regular RAC,
- you can use the same connection multiple times—in RAC, you had to
- reconnect to the server for every request. This changes how message
- receiving works.
-
- Receiving messages
-
- Since the connection can now be kept alive and WebSocket uses messages
- for transactions, we can’t retrieve messages the same way as in RAC.
-
-
- Receiving messages in WRAC is done by sending a single packet to the
- server with two bytes. The first byte is 0x00
- , which indicates that you want to receive messages, and the second
- byte is either 0x01 or{" "}
- 0x02. These two bytes work the same way as in
- RAC.
-
-
-
-
+ Go Back
+
+
+ WebSocket Real Address Chat Protocol
+
+
+ WRAC (WebSocket Real Address Chat) is a community-made successor to RAC
+ that uses WebSockets instead of TCP. It uses the same requests as RAC,
+ but you should send data in binary format. Unlike regular RAC, you can
+ use the same connection multiple times—in RAC, you had to reconnect to
+ the server for every request. This changes how message receiving works.
+
+ Receiving messages
+
+ Since the connection can now be kept alive and WebSocket uses messages
+ for transactions, we can’t retrieve messages the same way as in RAC.
+
+
+ Receiving messages in WRAC is done by sending a single packet to the
+ server with two bytes. The first byte is 0x00,
+ which indicates that you want to receive messages, and the second byte
+ is either 0x01 or 0x02
+ . These two bytes work the same way as in RAC.
+
+
);
}