On mastodon.social Canageek and I were discussing implementing a social network without a database. Just text files on a server and a script. That led to this. ---- Here's an idea for a social network that would only need text and would be straightforward to implement. It's a writing game called collab. An initial post is the start of a story. Replies continue the story. It's a single linked list like a chain. Not a tree. Only text. No pics or media. The main display is chronological with all posts and replies displayed. If you click on a post or reply the thread is shown reverse chronological or story order for reading or continuing. So after the last post there's an invitation to write more. Not so sure about how to implement endings. Quoting Mandrake: "My mother would insist we play something similar around campfires, BBQs, etc. It was all oral. Someone would start the story, set the scenario, then we’d go around the fire/table/whatever and each person would add their own next scene/events, and so on. Which makes me wonder, how would you control the “next person” aspect, or select the next piece from a flood of replies? Seems you would need to designate the next contributor somehow." First come first served. If there is a problem with a flood of replies we might have to address that. I don't really see that happening in a niche idea like this. I worry more about stories out there flapping in the wind because no one is adding text. It might take a dedicated group willing to check in once a day and contribute. I do think there should be a default option requiring the next segment to be written by another author. If you want to write all the segments use a text editor. I also have an idea about ending stories and forking stories. I'm working on a document now. (That's this document I'm talking about there.) ----- Implementation document ----- This is one suggestion for implementing this idea. Not the only or the best suggestion. Just one suggestion. It's the way I would do it. Please contact me if you're interested or if you see problems/have suggestions. Email hairylarry@deltaboogie.com. ----- Implementing users in text files ----- From a form collect email address, username, password. Assign a user id. Sequential is fine. 6 or 8 digits. This should never appear but is required so the email address can be changed. In a users directory create a file user_id.txt. (In order to scale this you might want 10 folders, 100 folders, ... based on the initial digits in the user id.) The file has three lines, email address, user name, and a hash of the password. When passwords are entered they are hashed and compared to the stored hash. Actual passwords never leave the script. I think you can see how easy it will be to set up email confirmation, forgotten passwords, and CRUD to manage the user info. Logins are made persistent with a single cookie. Implementing users is not necessary for a test implementation of the application. Users can be invited and manually created during testing. User management in text files is an interesting problem and should be coded as a separate module so the user management code can be used in other applications. ----- The data structure ----- The posts are stored per user. Each user gets a directory, user_id. Each post gets a file named YYYY-MM-DD-HH:MM:SS.txt. Alphabetical sorts give chronological and reverse chronological order. Each text file has two or three parts, top line, content, optional bottom line. The top line is either: :TITLE:The Title Of The Story or :PARENT:filepath/name of parent post or :TITLE:The Title Of The Story:FORKEDFROM:filepath/name (see below) The content has some length restriction enforced at entry and is saved as alphanumeric only with limited punctuation allowed and all other symbols stored in ampersand notation. i.e. ". This may be implemented with a language specific safe entry function and is included to avoid injection attacks. Basically if it doesn't look like text and it might look like code we don't want it. The optional bottom line is: :CHILD:filepath/name of child post This creates a doubly linked list so from any post in the story the entire story, to date, can be constructed. ----- All posts ----- There is an allposts directory with text files for each days posts named YYYY-MM-DD.txt. As posts are made they are appended (prepended?) to this days file as filepath/name. To scale the application this could be broken into folders like YYYY or YYYY-MM. ----- Configuration ----- Configuration is done in config.txt for things like the instance title, explanatory text, and the path to the application root. So filepath/name can be stored from the application root and the application root does not have to be coded into the application or the data. ----- Ending stories ----- Any writer can end a story by typing The End as the last line of their post. ----- Forking stories (Cloning may be a better name.) ----- Writers can fork stories, ended or not. Forked stories should have a new title. They will also need a forked from entry (:FORKEDFROM:) after the title on the first line of the text file to preserve attribution. At the time of forking the forker will have an opportunity to flatten the existing story to a single post and edit that post. Hence the need for the forked from attribution chain. Unending stories. Forking a story without flattening it and editing out The End from the last post will unend a story. Perhaps the writer of the initial post should have the option to retain the original title with the ended story having an end date and time appended to it. This will also make it posible to rewrite an ending. Not necessary for the initial test. ----- Attributing stories ----- Licensing - I think Creative Commons, Attribution is the best license for submitted content. I think a required checkbox as part of account creation is the best time to explain this. I think the code should be GPL. Since the stories are CC-BY it is important to attribute all the authors in stories, forked or not. A list of contibutors can be a comma delimited list of all the writers using their current user names. Maybe there should be a flatten option that displays the story as a single text file with the list of contributors included. Not necessary for the initial test. ----- Issues ----- User name uniqueness - Once a user name is claimed it should become unavailable. An exception to this could by anonymous allowing writers to choose to remain anonymous with a handle or user name. This could be implemented in a username directory with files username.txt that are soft links to userid.txt in the users directory. Username updates will have to make changes to the filename in the username directory. Anonymous users will not have a link to all of their posts like named users do since there may be more than one anonymous user. Banning - I prefer not to think about this but spam is a thing. I guess we can ban by email address. Banning may require selective post deletion and repair of the linked lists. This should done in an admin interface which will be required to edit config.txt anyway. None of this is necessary in a test implementation. Account deletion - Obviously this is a problem because it will leave holes in the stories or holes in the attribution chain. So I think the user id should be retained and the user name should be changed to anonymous. If the writer chooses to anonymize herself by deleting her account she should be allowed to deanonymize using her email address with an interface similar to the forgot password interface. There is no guarantee her old username will remain available. Like Banning, anonymous users and account deletion do not have to be implemented in the initial tests.