]> Git in Space - website/commitdiff
Added more to messaging article
authorMira Ayre <mi@boxin.space>
Sat, 7 Aug 2021 00:06:50 +0000 (01:06 +0100)
committerMira Ayre <mi@boxin.space>
Sat, 7 Aug 2021 00:06:50 +0000 (01:06 +0100)
Also got rid of the videos cause they're p crap ngl

12 files changed:
www/videos/atdoomsgate.webm [deleted file]
www/videos/bigandchunky.webm [deleted file]
www/videos/closer.webm [deleted file]
www/videos/dangerous.webm [deleted file]
www/videos/index.cf [deleted file]
www/videos/iwish.webm [deleted file]
www/videos/spain.webm [deleted file]
www/videos/thelessiknowthebetter.webm [deleted file]
www/videos/thunderbirdsarego.webm [deleted file]
www/videos/wireandflashinglights.webm [deleted file]

index a53e602b92d2730d838f3c7c76bbb2160bf4468f..ca342cdd1d22f9d0ee5ac84930f6bb75dd6463af 100644 (file)
@@ -120,3 +120,70 @@ pass on an outgoing message, and the server needs to request the client update
 it's visualisation of the messages that have been sent to a room. This would
 likely be achieved using some sub-protocol on top of a WebSocket for example.
 WAMP springs to mind.
+<b>Some server implementation ideas</b>
+Let's define some heuristics. Let's say the average length of a message is 100
+characters. Let's also say the average 1:1 chat sends about 100 messages per
+day. If we have 100% efficiency in message storage (i.e. there is exactly 0
+non-message data being stored alongside them), then that's 10,000 characters per
+day or 10KB. That means it'll take 100 days to reach 1MB, so in a year you're
+only generating 3MB of data for a 1:1 room which is really tiny. `grep` can do a
+search through that in a couple of seconds which is easily on-par with the
+experience I've had searching for messages in chat programs in the past.
+What this means, is that we can safely forego the use of a database for message
+storage and instead use a flat file. We can make this even better though. Let's
+break up a room's message history into files each roughly 50KiB in size. As we
+send messages to the room, we just append them as lines to the most recent file,
+and if the file goes over the 50KiB limit we just create a new file and start
+appending to that. What this does is make it trivial to implement paged chat
+history. The client can connect to a room and say "hey server can I have the
+most recent chat history?" and the server will respond "yes of course here's
+page 23", then if the user starts scrolling up the client can say "hey server I
+also need page 22 now" and the server can give it to them.
+This also makes pruning old messages easy as we can simply delete old files
+rather than deleting the start of a file that's still live and being written to.
+And on top of that, referencing messages becomes fairly elegant too as we can
+tie it directly to this paged system. Rather than seeing large opaque integers
+as message identifiers, instead it can be "page 14 message 243" which - while it
+tells the user very little - is much more memorable. This is only a real
+advantage in the subset of cases where someone wants to reference a message but
+can't simply copy/paste the message id though.
+<b>Message storage format</b>
+A message has a lot more information connected to it than just its contents, so
+we need this extra information to be stored alongside it. By storing each whole
+message object on a single line in the file we can make iterating over them very
+simple, so we need some kind of data structure that we can fit on one line. This
+could be minified json, or it could be something as simple as csv.
+The information we need to store in a message object is:
+* The message contents
+* Time stamp
+* Author
+* Reactions and the authors of the reactions
+* The parent message if this is a reply to something
+Most of these are single pieces of data and so can comfortably sit in a single
+field. The reactions are a little more complicated unless we decide that our csv
+can have an arbitrary number of columns on each line. So then a single line
+could look something like this:
+       <timestamp>,<author>,<parentID>,<message>,<reaction1>,<reaction2>,...
+The time stamp could be a unix timestamp or an ISO stamp. That's up to the
+implementation. The author can be a username *or* preferably a short hash
+uniquely identifying the user based on their public key as this allows for
+username changes not to break the message history. The parent ID would be the
+reference of the message which we could store in some `<page>;<message>` format
+as described earlier, the message would just be a quoted string and characters
+like quotes and newlines would be replaced with escape sequences as of course we
+can't store the actual newline as it would break our csv. Finally, each reaction
+would need to be a user identifier (like the short hash) combined with an emote
+identifier. This can be either the emoji character itself or an `:emote:` style
+string for example.
index 7eacb4a65326fb50d7cc4e53ac8e36016277de43..a7dfd1f861f0c647a10c0ecec89be26c1373f8d6 100644 (file)
@@ -28,9 +28,6 @@ Music archiving on <a href="https://open.audio/channels/oliea">Funkwhale</a>
 <a href="git">git</a>
        My coding projects - all open source.
-<a href="videos">videos</a>
-       Videos of me dancing around my bedroom playing my bass to various pieces
-       of music.
 <a href="articles">articles</a>
        Disorganised ramblings about whatever I feel like I want to talk about
        at the time.
diff --git a/www/videos/atdoomsgate.webm b/www/videos/atdoomsgate.webm
deleted file mode 100644 (file)
index 5d8e62b..0000000
Binary files a/www/videos/atdoomsgate.webm and /dev/null differ
diff --git a/www/videos/bigandchunky.webm b/www/videos/bigandchunky.webm
deleted file mode 100644 (file)
index 93beec1..0000000
Binary files a/www/videos/bigandchunky.webm and /dev/null differ
diff --git a/www/videos/closer.webm b/www/videos/closer.webm
deleted file mode 100644 (file)
index d5ba602..0000000
Binary files a/www/videos/closer.webm and /dev/null differ
diff --git a/www/videos/dangerous.webm b/www/videos/dangerous.webm
deleted file mode 100644 (file)
index a8c9045..0000000
Binary files a/www/videos/dangerous.webm and /dev/null differ
diff --git a/www/videos/index.cf b/www/videos/index.cf
deleted file mode 100644 (file)
index 1876701..0000000
+++ /dev/null
@@ -1,11 +0,0 @@
-<!DOCTYPE html>
-       <title>Box in Space - videos</title>
-       <link type="text/css" rel="stylesheet" href="/style.css">
-;;indexh '*.webm'
diff --git a/www/videos/iwish.webm b/www/videos/iwish.webm
deleted file mode 100644 (file)
index 117a812..0000000
Binary files a/www/videos/iwish.webm and /dev/null differ
diff --git a/www/videos/spain.webm b/www/videos/spain.webm
deleted file mode 100644 (file)
index 11d836a..0000000
Binary files a/www/videos/spain.webm and /dev/null differ
diff --git a/www/videos/thelessiknowthebetter.webm b/www/videos/thelessiknowthebetter.webm
deleted file mode 100644 (file)
index 5a5789a..0000000
Binary files a/www/videos/thelessiknowthebetter.webm and /dev/null differ
diff --git a/www/videos/thunderbirdsarego.webm b/www/videos/thunderbirdsarego.webm
deleted file mode 100644 (file)
index 609c0fe..0000000
Binary files a/www/videos/thunderbirdsarego.webm and /dev/null differ
diff --git a/www/videos/wireandflashinglights.webm b/www/videos/wireandflashinglights.webm
deleted file mode 100644 (file)
index 3bf3791..0000000
Binary files a/www/videos/wireandflashinglights.webm and /dev/null differ