Hi Andrew Lalis, please see this:

PS D:\Downloads> java -jar .\concord-server.jar
server-config.json does not exist. Creating it with initial values. Edit and restart to apply changes.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Adding index on "timestamp" field to collection channel-95a19ca9-d368-4948-a49c-a269d17bb2c6
Adding index on "senderNickname" field to collection channel-95a19ca9-d368-4948-a49c-a269d17bb2c6
Adding index on "message" field to collection channel-95a19ca9-d368-4948-a49c-a269d17bb2c6
Exception in thread "main" java.net.BindException: Address already in use: bind
        at java.base/sun.nio.ch.Net.bind0(Native Method)
        at java.base/sun.nio.ch.Net.bind(Net.java:555)
        at java.base/sun.nio.ch.Net.bind(Net.java:544)
        at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643)
        at java.base/java.net.ServerSocket.bind(ServerSocket.java:388)
        at java.base/java.net.ServerSocket.<init>(ServerSocket.java:274)
        at java.base/java.net.ServerSocket.<init>(ServerSocket.java:167)
        at nl.andrewl.concord_server.ConcordServer.<init>(ConcordServer.java:85)
        at nl.andrewl.concord_server.ConcordServer.main(ConcordServer.java:231)
PS D:\Downloads> java -jar .\concord-server.jar
Loaded configuration from server-config.json
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Exception in thread "main" java.net.BindException: Address already in use: bind
        at java.base/sun.nio.ch.Net.bind0(Native Method)
        at java.base/sun.nio.ch.Net.bind(Net.java:555)
        at java.base/sun.nio.ch.Net.bind(Net.java:544)
        at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643)
        at java.base/java.net.ServerSocket.bind(ServerSocket.java:388)
        at java.base/java.net.ServerSocket.<init>(ServerSocket.java:274)
        at java.base/java.net.ServerSocket.<init>(ServerSocket.java:167)
        at nl.andrewl.concord_server.ConcordServer.<init>(ConcordServer.java:85)
        at nl.andrewl.concord_server.ConcordServer.main(ConcordServer.java:231)

I'm using in case it matters:

openjdk 17 2021-09-14
OpenJDK Runtime Environment Temurin-17+35 (build 17+35)
OpenJDK 64-Bit Server VM Temurin-17+35 (build 17+35, mixed mode, sharing)

Am I doing something wrong?

Dear Concord maintainer,

I would wish for a serialisation format that is friendlier to non-java languages so that I can implement my own Concord client in an inferior programming language such as Bash or Rust.

Sincerely,

A Concord enthusiast.

PS nice music in your video

Currently, the server interprets each new connection as a completely new, unknown user. This is annoying for things like private messages, which become inaccessible as soon as you disconnect, never to be seen again.

For my own planning purposes, this is how I plan to implement the idea of persistent users, where a user can disconnect then reconnect to the same server.

When connecting, for the first time, the user will receive in its ServerWelcome message a private session token. The client saves this somewhere hidden, along with the server's address. The next time the client attempts to connect to the same address, it will provide the session token in its Identification message. The server, when processing incoming Identification messages, will check for the presence of such a session token, and if it is present, the client's information (most importantly, their unique id) will be loaded from a database collection.

Each time a client connects, the server will always generate a fresh session token, and the token which a client may have just used to connect will now be invalid.

Once connected, a Client can't leave unless the entire Server is closed. Even if the JRE of the client has stopped, the Server still lists them as there as well as the chas Users list.

Add support for so-called "thread" channels, which are a subset of channels that follow the rules listed here:

• A thread is uniquely identified by a single message's id.
• It should be presented to the user when a message is known to be the starting point for a thread, so that the user has the option to navigate to that thread.
• All messages within a thread should be stored in the same message collection as the top-level channel that contains the thread (to avoid creating a new collection for each thread, which is very inefficient).