From c34e5b5124659b4ff0f82f093cebd486bd978530 Mon Sep 17 00:00:00 2001 From: nebula Date: Sun, 20 Apr 2025 21:01:15 +0000 Subject: [PATCH] update readme --- README.md | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 01e9c73..1da9a01 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,30 @@ # bink -serverless forum for tilde.town \ No newline at end of file +serverless forum and microblogging for tilde.town + +# object logic + +each system user that chooses to use bink will have a folder in their home directory called `.bink/`, which will be populated by items named after the epoch-nanoseconds time of creation. the contents of each item are json formatted. the following structure defines what a post is: + +``` +{ + "body": "this is the body of the post, as a string", + "forum": false boolean OR "the title of the forum thread" +} +``` + +from the path where the object is stored, ex. `/home/nebula/.bink/1745182221128478782`, the user who posted the item and the time it was produced can be inferred. each post object therefore has 4 pieces of data: the `body`, the `forum` indicator (more on that in next paragraph), the exact time the post was produced, and the user who posted it. the client will iterate over system files by using the `/home/**/.bink/*` glob, collecting all of the user objects without using a central server like `bbj` + +when `object.forum` is false, the `body` of the the object is used to make a microblogging post by the user. if `object.forum` is a string, this is the title of the thread this post belongs to. there is no additional data specififying if this is the first forum post or what order it came in the thread, as this information can be inferred from the object filename + +## potential flaws + +* users who choose to delete or tamper with the contents of their `~/.bink/` directory will cause some confusion in threads, where their posts are missing, which would be especially odd if the first post were to vanish. the program would therefore show the `n` posts which came after the original post, losing important context +* scales poorly: client will need to implement some sort of pagination logic if many thousands of posts exist, or the program will be very slow. every file on the system must be iterated with each subsequent update. in 10 years of use, this serverless approach may become cumbersome. + +## upsides over bbj + +* there is no server to maintain or have potential issues with +* no potential for centralized data corruption +* zero passwords or necessary authentication, all user interaction is based on the logged in user and the permissions they do/dont have to write in the chosen directory +* ability to edit your own posts and own your data \ No newline at end of file