💾 Archived View for gemini.dimakrasner.com › tootik-new.gmi captured on 2024-06-16 at 12:03:29. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
tootik is maturing quickly, and I use it for many things: for example, I follow bots that monitor news sites and publish summaries on Mastodon, allowing me to consume news (and replies) in plain text form through a Gemini client.
When viewing a post, tootik shows mentioned users, links [...] and a compact lists of replies. Every reply is accompanied by a link to the same view but with the reply as the "post", so one can see replies to this reply. To read all posts in a thread, the *user* (yes, the human user) needs to follow this link recursively and this gets annoying very quickly, because it's easy to forget the context and one needs to find the link (which is not always in the same position on the screen) to follow it. Also, this doesn't scale: if a post has two replies, and both have more replies, it's hard to read one "branch" of replies, navigate back to the "junction" where this "branch" begins and repeat the recursion for other branches until you read everything, unless you have a "map" of the thread.
Now, tootik provides such a "map": posts with nested relies are accompanied by a link to a "thread view" shows all "branches" and sorts "sibling" replies chronologically. It's much easier to follow a conversation (or a heavy debate) now, especially if you use a client that marks already visited links, like Lagrange.
I think at least 3 users asked for this feature, and so far I haven't received negative feedback.
https://github.com/dimkr/tootik/commit/84a388d2bf5993492652b81dcc52441b4256cb84
tootik now allows users to vote on polls, view a poll results graph and publish Station-style polls.
Poll support is important from a project maturity viewpoint, because it creates many corner cases that must be handled (like the visibility of "vote posts").
https://github.com/dimkr/tootik/commit/0063bd52fb04cf129e708f8377ba343f8e06e78d
https://github.com/dimkr/tootik/commit/ce6fb8da66c4e7cca4ff41be2c23362293724ffe
https://github.com/dimkr/tootik/commit/1871ce83210b6cf04081e9d6905e0550760e2d50
The addition of polls adds more "rules" one needs to know when publishing posts, making some kind of documentation that's integral to the tootik UI (as opposed to, the git repo) a necessity.
https://github.com/dimkr/tootik/commit/8bcdcc628044add5b5668c193d42186649ee4476
tootik now sets the endpoints.sharedInbox property on users (to the inbox of the special "nobody" user), so a tootik instance with two followers of the same user on another server receives only one request when this user publishes a new public post, or when a poll published by this user receives more votes. This reduces resource consumption a lot, and the number of requests tootik needs to handle has dropped significantly. (I still see some duplicate requests that get filtered; I guess some serveres still have old cache with unspecified endpoints.sharedInbox.)
In addition, when a user of a tootik instance has two followers on another server, both with the same shared inbox, tootik now sends only one request to this server when the the user publishes a new public post. This reduction in the number of outgoing requests speeds up delivery of posts to other servers.
Poll results are sent to servers with followers of the poll author, so a long list of active polls is not a big problem even if the poll author has many followers (assuming they have "shared inboxes" and actually share them).
https://github.com/dimkr/tootik/commit/b52c2b30025a7fa459369922754cf2ab0d2a3006
https://github.com/dimkr/tootik/commit/cde8fff0a9d3eb50c4a7b4e7c9b3014f40d379d6
https://github.com/dimkr/tootik/commit/18dc00c58096767f32df2e3ac64f06d0db772b28
Previously, tootik allowed anyone who knows the "secret" hash of a post ID to see the post. Most post IDs contain something that's hard to predict, like a timestamp or a sequence number, but there are many corner cases where one can "discover" this "secret" (for example, through another post).
Now, tootik filters content by the "to" and "cc" fields, and all fixed corner cases are reproduced in newly added tests.
https://github.com/dimkr/tootik/commit/87d9ca2658f610c463d0599408ff68f42f107da8
https://github.com/dimkr/tootik/commit/9265a8b803350175bd124b14cf8cb33f5c1f99f3
https://github.com/dimkr/tootik/commit/2a3dc897a2bcdc702c1f464b7ee1b546379553dc
https://github.com/dimkr/tootik/commit/2fc6a7515784051f6896b091b178518d45675b85
https://github.com/dimkr/tootik/commit/6003654115e572c872b81067e1f5e498c727eb3d
The slowest pages (/users and /users/inbox) are still slower than anything else, but they're much faster now. Previously, a big query used to match all posts within a time frame against the user's ID, followed users, followed groups and posts by the user (to show replies), and it's impossible to speed up such a query using an index. The query reads many columns from the posts table, forcing it to do a slow "scan" that checks for many conditions on many posts, and a big index would only slow down insertion of posts without speeding up the query. Now, each "why should I see this post" condition is a separate (and fast) query: search of posts by group can use one index, search of posts by author can use another, search for replies to posts by a specific author can use another, and all queries can run in parallel to maximize utilization of the disk's read bandwidth.
With all these new features, my instance still runs comfortably on a $5/mo VPS. Total RAM consumption (with the underlying OS and evreything) is around the 120 MB mark, and CPU consumption is usually <=5%.
https://github.com/dimkr/tootik/commit/c506d9457b1a4b6805e3bda4abe89ef362d14b2d
https://github.com/dimkr/tootik/commit/01921857d65719315eeb2fb13ab3489f7449f72f
tootik's test coverage has increased a lot: pretty much every change is now accompanied by tests and bugs are fixed once they have tests that reproduce them (then act as regression tests). It's much harder to write broken SQL now.
tootik now supports guppy://, in addition to Gemini, Gopher and Finger. This new protocol will be useful for low latency consumption of public content like news, and every user that consumes "feeds" (like the federated posts feed) over guppy:// instead of gemini:// reduces load on the server. I can see myself using this on the long way to work, if and when Lagrange for Android gains guppy:// support (I'm already using guppy:// on two devices!). TLS handshakes time out often due to dodgy mobile signal, while guppy:// allows pages to be received in a single burst of packets, without a preceding three-way handshake or key exchange.
https://github.com/dimkr/tootik/commit/bfb085ec82a655e04238da023c527d53ba0ff53d