* declaring tomo-rslight dead a month ago was incredibly helpful because it allowed me to put the endless mental arguments about how to proceed with the project to rest.
> boiling it down: the NNTP protocol locked tomo down into a specific hierarchical relationship between groups (e.g. animals.dog.chihuahua). worse, NNTP made modern necessities like editing and deleting posts almost impossible.
> i don't know about you, but my posts are so rife with errors that it generally takes me 3-5 edits after the fact. worse, sometimes I write something so dumb and hit send before thinking about it. I have to delete the post 8 seconds later before the unwashed masses can read it. imagine *not* being able to do that in 2026.
* if you've been reading this development .plan for a long time, you might remember a concept that I floated around a long time ago: that each tomo shard is like an izakaya you'd find in a Tokyo alley.
> You part the noren below the dusty sign announcing the name of the shard. Stepping inside, a group of old friends is huddled together at a table in the corner, arguing about sports and politics. A larger group of English-speaking ex-pats nod politely as you step inside, trying to decide if you're one of the regulars. At the bar, the owner tends to four visitors who enthusiastically tell stories to one another about their recent travels; they turn around and welcome you to have a seat beside them. To your left are private booths: a business meeting with a group of three takes place in one; a hushed romantic dinner between two people in another.
* there are a bunch of design decisions implicitly made in the izakaya that may not be evident at first glance:
- the izakaya is a private space for public discussions: when you're outside, you see and hear nothing; just stepping inside lets you listen-in and even participate.
- the social space of the izakaya is sub-divided into private, semi-private, and public discussions. the bar, with its friendly, transient visitors, welcomes *anyone* to join in and participate. the table of ex-pats is one degree more private, welcoming any new ex-pats but not welcome to non-expats. the table of old friends is public - you can hear everything they're saying, but participating in their discussion is strictly invite-only. the booths along the walls are totally private: you can't listen-in, you can't talk, unless invited by the owners.
* what I wanted to maintain from the beginning with tomo was the ability to have this huge mix of private and public discussions. this meant giving shard and room owners a bunch of toggle switches to set their preferred degrees of public and privacy.
> none of the above is meaningfully possible with traditional NNTP, which was always meant to be fully public.
! sure, there is plenty of forum software out there that can already do some of this.
> but what I don't see is forum software that can manage private/public conversations and federate each shard with one another over the network, and allow for important functions like editing and deleting posts.
> what I propose is something like this:
> each tomo shard carries its own registered users
> each shard shares with other shards on the network its list of public rooms (discussion groups), and list of public topics in each room, but does not share the content of the messages/posts in each topic.
> click on a post, and the local shard (tomodori.net) asks the remote shard (jackson.tomo.city) if vga@tomodori.net is allowed to read that post. The remote shard (jackson.tomo.city) replies "Sure, it's public, anyone can read posts in that room" and sends the post to the user's browser.
> want to reply to a post? The local shard (tomodori.net) asks the remote shard (jackson.tomo.city) if the user is allowed to reply to posts. The remote shard says "Okay, well: that user's account doesn't exist here, but after checking the room's permissions, I see that vga@tomodori.net is allowed to post in that room. Sure, send me their post and I'll add it to the discussion."
> what I don't want is the push-based Federation system that Mastodon (and most ActivityPub-based servers) rely upon. it's wasteful, and it creates huge, complex, and high-overhead management software.
? is a pull-based architecture still possible using ActivityPub? Is using ActivityPub as the base protocol for server-server and server-client communication even necessary?
> Django supports pull-based Federation, so we at least know that it's possible.
! what's the upshot of all of this? tomo is getting a reboot as a modern, pull-based, federated network of discussions. no more NNTP, no more RSLight, with an even simpler design. all written in PHP.
.............................

! fuck it. i'm declaring project bankruptcy with rslight-tomo.
* after futzing around with tomo's (rslight-based) code for the afternoon, i realized that it's such an ensnarled mess that it's not worth trying to untangle the old rslight code from the tomo code i wrote over the last couple of years
* it reminds me a little of the source code for adventure game studio - a game building IDE that is over 20 years old.
> at some point open source projects have changed hands so many times that it's like trying to renovate a 300 year old house. the foundation was built in the 16th century by louise, the bedrooms in the 17th by raoul, and the bathrooms in the 18th by edward. you need to run new electrical wiring throughout the house, but none of it was ever built to accommodate conduits in the stone walls.
> you don't know why louise, raoul or edward designed things the way they did, and you can't ask them now. but you assume there was some kind of rationale to their decisions, so you work around their messes. it seems ok at first. the wiring runs on top of the stonework, but you've found a way to hide it in the crown moulding. you've got it running dangerously close to the water pipes, and god forbid you ever have to fix a broken wire, because you couldn't use conduit anywhere.
> after years of blood, sweat and tears, you've got howl's moving castle. your friends who visit call it quaint, but no one really wants to live there.
> that's what happened with RSLight. it was originally written by Florian Amrhein in 1999 until the mid-2000s. then over a decade later, Retro Guy picked it up and began extending those php scripts with his own particular code.
> and then i picked it up in 2023, and began trying to rewrite *both* retro guy's and florian's code.
* the truth is: louise and raoul and edward never knew what they were doing in the first place. they were all renovators just like me, using their meagre knowledge to solve problems particular to their time and place. the house was never built to accommodate the 21st century.
* it's not pretty. and worse, it's not maintainable. other people love howl's castle precisely because they don't have to live there; howl does.
.............................

* back in mid-2023 when i first thought out loud about the idea of a decentralized NNTP forum network, i had no specific sense of what kinds of tools out there existed.
! I tried many different NNTP servers and web-based front ends, and the outcome with all of them was the same: these are absolutely miserable to build, design, extend and administrate. all of them involved cryptic CLI-driven commands, cron jobs and hand-editing text files.
> many of these NNTP packages used flavour-of-the-year programming languages, or painfully huge chains of python scripts. this is what I called Programmer-Thinking in a different blog article, but - less charitably - it's a form of Linux-thinking: the belief that the CLI is enough for anyone, and that GUI-based front-ends are wasteful or needlessly extravagant, like a Fabergé Egg.
> and then I found RockSolid-Light. it was built from top to bottom with PHP - a language that started its life from the acronym for "Personal HomePage".
> RSL wasn't great. It had all of the same configuration and administration problems as the other CLI-based packages, but it had a few things going in its favour that none of the rest had: RSL had a web frontend for end-users, RSL implemented the NNTP server daemon in PHP, and - most importantly - the developer (Thom Miller/Retro Guy) was a solo developer who welcomed code contributions/suggestions/bugfixes from naive developers like me.
> I knew that Retro Guy had no serious plans for making the back-end more friendly for people like me. So instead of trying to turn RSL into the server that I wanted to use, I decided to fork RSL into tomo.
* I re-designed the entire tomo interface around the amber monochrome text interface you see on this blog. 95% of the work I did was redesigning the interface to be as user-friendly as possible. At the current time, it looks almost exactly the same: navigation buttons along the top, and action buttons (based on the context you're in) at the bottom. Think of it like sitting at your local public library's DEC VT-320 terminal.
* this all went well, and I got it very close to a public alpha.
> I took a brief break to build kiki - a tiny homepage construction kit. this smallweb toolkit was extremely successul because it did exactly what it needed to: let you build websites very quickly using a very simple markup language that was better than markdown.
> and then Thom/Retro Guy died. RSLight servers disappeared from the internet, and without the sole developer the project effectively died. aside from losing a colleague, it presented a problem: I no longer had someone to bounce tomo/RSL development ideas off of. Thom knew the software inside-out, and was always very generous with his time.
! today, tomo appears to be the only fork of RSLight that is still alive. so what now? i'll be honest: i was very tempted to trash the project and move on. I have a half dozen other neglected development projects and books and a podcast to devote my research time to.
> and then I thought about Thom and the thousands of hours of his life that he put into his final project. his dedication was infectious. and in 2026, we need a decentralized forum more than ever. but I sure as hell don't want to be responsible for taking over someone else's open source project. that's almost as bad as adopting their kid. hard pass.
> so here's what I'm going to do instead (ROADMAP):
* I'm going to spend the next few weeks rewriting the living shit out of tomo. I'm stripping out all of the RSLight stuff I really hate. Thom's coding style and code structure is absolutely shitty, and I've been fighting with it for years. no more form submission for every godforsaken interface command. no more hardcoded tables. a mobile phone-friendly/responsive UI.
* i'm integrating kiki and bug markup with tomo. that means that each room (discussion group) will have its own kiki (homepage-wiki) that users can edit and customize. this is basically how reddit's wiki tab works on subreddits.
* when that is done, i'm going to offer a closed alpha for a handful of users.
* when i've able to iron out the worst of the bugs, i'll announce a public alpha on mastodon.
.............................

* although I am months late in finding this out, a short eulogy for Thom Miller/Retro Guy, the creator and maintainer of RockSolid Light (RSL) - a web-based NNTP server
> i have rarely known someone so dedicated to their passion project as he was. many of the features RSL came to support, like encrypted private messaging between server shards, were because folks like me naively asked "would this be possible?". suddenly, a week later, thom would post an announcement that the feature now existed and was ready for testing and feedback. sometimes he'd disappear for a week or two, only to return with an apology that he had been sick from his ongoing cancer treatments.
> I consider him to be one of the most dedicated developers I've ever had the pleasure of working with, and Tomo - which is a fork of RSL - would have never existed without his constant willingness to lend a hand.
> his death was announced on usenet back in may. thom had been fighting pancreatic cancer for years through various treatment regimens. my condolences to his wife, who I'm sure lost a lot of time spent with thom as he worked on RSL.
.............................

* I was recently re-reading an old sci-fi book called Ender's Game. One subplot of the story involves two kids who go online posing as adults, posting invective populist rants on political discussion boards.
> At first, the posts are disregarded by the real adults on the boards, due to their puerile writing style.
> over time, the kids learn the social norms of the discussion groups, and slowly begin to receive positive feedback from other people. Their political agendas gain credibility, and as their writing improves, they become an accepted voice in the world of adults.
* when I was a teenager in the 1990s, a huge chunk of my time was spent exploring the world wide web, chatting with other people on IRC and in MMORPGs.
> at the time, my family and school life gave me no real voice or agency in how my life went.
> when I was 15-17 years old, I hung out with 20, 30 and 40-year-olds in cyberspace who assumed I was their age. that was partly thanks to my ability to type quickly and accurately.
> I wasn't always taken seriously by the other people in those online groups, because I could be a real pain in the ass sometimes. I was moody, prone to emotional outbursts, and had a poor sense of boundaries. y'know, just like a teenager.
* IRC channels and Ultima Online unknowingly became safe spaces to learn how to relate to adults, by imitating them, and being disciplined by them.
! emotionally, for me, a lot was at stake: I wanted the people in my channel to like me.
> conversely, nothing was really at stake for me too. when i pissed someone off, got booted or banned from a channel for being a little shit, I could just turn off the computer monitor and go watch TV. no one was going to come to my house and beat me up, or take away my possessions or put a permanent blotch on my academic record.
? I've begun thinking about the internet as a place where people of all ages and maturity levels can learn difficult lessons without life-altering consequences.
? in the 1990s, there used to be a firewall between "RL" (real-life) and online life. ever since social media became tied to real names and real faces - on facebook and instagram specifically - that firewall has disintegrated.
! anonymity comes with tremendous downsides of course - but those downsides are only evident when that firewall between the real world and online world has been broken.
> when that firewall is maintained, then negative online behaviour carries much less power in someone's life. they can walk away from the online world to the real world, or vacate the real world for the safety of the online world.
> perhaps Tomo needs anonymity controls that allow people to give themselves a degree of safety, so they can role-play in a safe environment, where they're able to make errors without consequence.
.............................

* after posting that Eris-Free Net wikipedia article the other day, it made me think about how to deal with misbehaving shards on tomoNet, and how governance works on decentralized networks.
> when i started thinking about creating something like tomo years ago, i often thought about Ultima Online as - not so much a model for - but an example of a network of online communities that was always interesting and sometimes frustrating to deal with
* in-game, for several years, UO really was the "wild west" of online communities - so much was left up to players to figure out. for a long time, there were no game mechanics that enabled players to enact governance of their own (e.g. creating towns, villages, provinces and local laws). the outcome of this was that most often a kind of hillbilly or street justice, or outright dog-eat-dog existence, became the norm.
> this was great for player-killers and people who loved strife. it added some intensity to the game that no other game had, or in my view has ever had since. (WoW/EQ/etc all elected to bolt everything down and render the world in nerf). this was, simultaneously, horrible for players who just wanted to craft bows and arrows and bake bread and chat with other people. they often became targets for sociopathic players.
> they even went so far as to exact team justice on bug exploiters - tim cotten's article That Time We Burned Down Players' Houses in Ultima Online is hilarious.
> outside of the game, however, the OSI team tried to implement some mild community-led governance, like the House of Commons Chats. these were irc convos with team members that let people ask questions, bring up grievances, and make suggestions for implementing/balancing game mechanics.
* BBSes also had governance-by-sysop/god, FidoNet with network coordinators, and USENET with its backbone cabal.
* tomoNet - a network of tomo shards that agree to all swap groups/posts with one another - is going to have to deal with the question of (self-) governance sooner or later. at the moment, tomoBBS has no specific controls for managing defederation and it does *not* use the ActivityPub protocol. it needs controls of some kind, and i need help thinking through what the options are, for a network based on NNTP.
* for the time being, i'll reading "From Community Governance to Customer Service and Back Again: Re-Examining Pre-Web Models of Online Governance to Address Platforms’ Crisis of Legitimacy" by Ethan Zuckerman and Chand Rajendra-Nicolucci.
> it covers the emergence of BBS and USENET governance and their decline. hopefully I can learn some lessons from it.
> epub/pdf here
.............................

* today i watched a fascinating mini-documentary on the alleyways of kyoto. it reminded me of the autumn of 2003, when i spent a week in kyoto with a friend. we stayed inside of a grubby old hostel - the cheapest in the city - called Uno House.
* Uno House was on a fairly wide alley, just a block away from the Kyoto Imperial Palace and National Garden. despite, or perhaps to-spite, the proximity to royalty, uno was unambiguously, a dump. stepping out from our "bedroom" - which was a series of former showers whose faucets still protuded from the walls, you walked into a hallway to the other rooms in the rat's maze. i awoke one night to use the bathroom, only to find that it was raining in the hallway... it turned out that what I had thought was a hallway, was in fact a gap between two houses, and there were no roof eaves between them so the rain fell freely into the hallway between guest rooms. This google street view pic, circa 2009, shows Uno exactly as I remember it. it looks quaint on the outside. it is the opposite of that on the inside.
* uno had a dark common room in the entrance, walls covered with handwritten notes in various degrees of english, describing the various rules and penalties for living in the hostel. "no guest in room between 11AM-4PM". "internet ¥100 10 minutes". "loitering fee ¥100".
* after our first night, my friend and i gathered with two other guests in the common room. an american woman, in her thirties, and an australian from Sydney. we sat together, drinking beer, and cracked jokes about this hostel that seemed to double as a minimum security prison for gaijin. it was almost like being in a neighborhood izakaya, drinking and laughing with locals.
* stepping into the alley at night, it was dead silent on the street. no one walked outside, and you could safely walk barefooted from uno house to the imperial castle without seeing a soul. at the end of the block, you might see another alley, this one entirely different in character than the one you just walked from. the alley makes you curious about who lives along it, and what strange shops might be hidden away there.
* i've lived in cities, towns and on a farm, and to date i've never experienced that kind of somnolent urban space before or since.
! it brings up a fascinating question: what is an alleyway?

> back in august of 2023, i wondered: what would this software be like, if it had been made to feel like the alleys of kyoto?.

"i thought about each tomo discussion group as a little izakaya you might find in a quiet hidden alley off the main streets of Tokyo. you step inside, and find either a collection of strangers who look up, surprised to see a new face... or a tightly huddled group of friends who look up and smile to see a familiar one. there is no word in the english language that adequately expresses this spatial peculiarity of urban Japanese life. the word "room", or "discussion group" or "forum" does not capture the intimacy and the ubiquity of the izakaya. each discussion group owner/moderator is like the owner-bartender of a tiny izakaya: picking the particular alley it can be found, responsible for the well-being of their patrons, the decorations on the wall, and for setting the tone of the place the moment someone new steps in."

* (i realize that this will all sound very nebulous to the reader, so please excuse the writing style - i'm trying to think out loud through an extremely difficult design problem below -)
? i never came up with a very satisfiying answer, except to map out some of the visual language that described them. but how do you turn words like "izakaya" and "alley" into software that people interact with?
* now that tomoBBS is nearing its pre-alpha (sometime in february), i'm thinking a lot more about tiny yet critical features that set it apart from phpBB and the multitude of online discussion forums. sure, it'll be decentralized with its own federated network... but to me, that's not quite enough to make it interesting software.
* today i'm thinking about alleyways as something more than mere urban connective tissue. in kyoto, they were something special. the alley that led to Uno House was itself a special place of its own: where walking from one end to the other, a dozen residents' families might have known one another for a century. it's a place where a local izakaya might be simultaneously frequented by generations of the same families, yet still welcome in strangers and curious tourists from the alleyway.
* how can I facilitate that experience in tomo? i'm thinking about that today, and i'd love to hear your thoughts on it.
> for instance: tomoBBS currently uses slash notation to organize its tomos: /pets/cats/black and /pets/cats/tabby both are found in the /pets/cats/ hierarchy. how could the slash notation be treated as a kind of alleyway or invitation to explore the rest of the hierarchy?
> a hierarchy always visually and mathematically implies a tree-like structure. but is it possible to re-imagine that as a grid system instead?
> i chose the domain tomo.city because it felt right. how could each tomo be understood as place in a city of little places with interconnected alleys?
> or more generally, what if we built software as a form of urban planning, instead of solution oriented design?
.............................

> after nearly an 18-month pause on development, tomoBBS has been back to full-time development for the past week. big changes:
+ the default skin has been mostly implemented, and now matches the cozy Datatrain Amber monochromatic styling you see on tomo's site.
+ rewriting any ancient front-end html generation code that relied on very old html standards like hardcoded tables, so the site properly displays on almost any kind of device, from 640x480 monitors to tablets and mobile phones. this is an old holdover from using old RSLight code. i still have tons of old code to strip out and replace.
+ defining standard nomenclature for tomoBBS:
       > a tomo is a specific discussion group or forum, e.g. /tomonet/pets/dogs/spaniels
       > a tomo can be public tomo or a private tomo. public tomos can exchange posts with other BBSes; private tomos are located only on a particular tomoBBS.
       > tomoBBS instances can run in solo mode or sharded mode:
       > a shard is a server or "peer" that connects to other shards, and exchange tomo posts with one another. all shards share identical public tomos and posts.
       > solo BBSes do not network with other shards, so they cannot exchange posts.
       > tomoNet is a specific network of tomo shards that will have its own rules about content and moderation.
       > tomo.city is the first tomoNet shard. it will run in solo mode for the first few months while we iron out bugs and improve the user experience. when tomoBBS is in good enough shape, i'll open tomoNet up to the public for new shards/peers.
+ homepages for each tomo have been implemented. now you can go to /tomonet/pets/cats/voids/home and you'll see a wiki-like homepage for the tomo.
+ i added homepages because they remind me a bit of MySpace, and allow moderators to personalize each tomo to their liking. reddit makes good use of these.
? what I haven't figured out yet is how to deal with syncing homepages across the network. i don't want to run into sync/conflict issues by trying to have each shard exchange homepage data. that would overly complicate the protocol. right now, i'm leaning toward having one shard containing the homepage, and all other shards link out to the homepage. i.e. tomo.city carries the homepage for tomonet/animals/pets/cats/tabby, but tomo.andrewsplace.com carries the homepage for /tomonet/animals/pets/dogs/terrier. each tomoBBS just exchanges links to each page with one another when they sync, instead of exchanging all homepage data.
+ homepages can be written in raw html, or use any markup language that the shard supports
+ added plugin support for markup languages (written in php): you add a markup language plugin to the configuration, and homepages can be interpreted using that language.
! a conceptual change to tomos:
       > internally, because tomoBBS is NNTP at its heart, all tomos are stored as standard USENET-style newsgroups like animals.pets.cats.tabby. this ensures 100% backwards-compatibility with NNTP servers and clients.
       > externally, on the web interface, tomos are displayed in this format: /tomonet/animals/pets/cats/tabby
       > there are two important aspects of the external display:
       ! /tomonet/animals/pets/cats/tabby shows which network the tomo exists on
       ! /tomonet/animals/pets/cats/tabby is hierarchical in nature.
       > if you visit /animals/pets/ it will show you a list of all tomos and posts that exist below it, like dogs and cats and dolphins and reptiles.
       > similarly, going to /animals/pets/amphibians/ will show you only tomos and posts related to amphibians.
? all message deletion is done locally for the time being, if only because "Post Nuking" or NNTP CANCEL is not implemented in RSLight. at some point, i'll have to figure out how to implement real NNTP message cancels, so post cancellations can happen across the network.
.............................

* when I last left tomo, I was dealing with two core problems:
(?) the encrypted user-to-user, shard-to-shard, messaging system wasn't working. this was a technical problem with either the implementation or the SSL libraries, and I spent 50+ hours trying to debug it with no progress
(?) i had no root design metaphor for tomo itself. is it reddit? tiny usenet? a frankenmix of the two? why should people use it instead of anything else already out there?

! all of the above left me at a standstill in August 2023. The technical problem was probably fixable, but I had burned weeks of development time trying to fix one single bug without making progress in other areas of the project. The creator of RS-Light (which tomo uses for 90% of its core functionality) was incredibly generous and helpful trying to help me figure out the problem, but it was becoming evident that both of us were stymied by the bug. One big bad bug.
! the design problem was even more troubling. I didn't want to keep building out software that needed a re-design from the ground up. if tomo was just a distributed form of reddit, I'd need to start re-designing the entire interface and functionality around reddit. And honestly? I don't love reddit. The basic forum system works okay, but it isn't pleasant to use. It basically turns out to be "imgur with comments" when you strip away all the cruft.
? okay, so what if I model it on barebones NNTP/usenet? why should anyone want to use tomoNet instead of USENET? does it offer anything that a straightforward NNTP server doesn't do already?

! I was conceptually stuck, and burned out on debugging. The project was no longer a joy to look at. So I did what I do when I burn out: I switch to other projects that can make progress. I started tinkering with game development in the winter of 2023, building prototypes with Adventure Game Studio.
> the prototypes quickly got hung up on limitations that came from AGS itself: its bytecode-compiled scripting system couldn't do any of the things necessary to make the kinds of games I wanted. It was so deeply designed around making LucasArts/Sierra adventure games that any other genre (like SimCity-style games) were nearly impossible to build.
> I became despondent. Tomo had lost traction for months, my game prototypes became hung up on engine limitations, and nothing seemed to be working.
> and then, a break in the clouds: in December 2024 - one year ago - I decided to throw in the towel on my 10 years of work as a hired-gun/contractor in the game industry. I re-invented myself as a game design Studio Tomodashi and decided to build out my own engine and game construction toolkit.
> from January-March 2024, I wrote a bunch of design documents and tried to force AGS into doing what I needed it to. Adding basic things like creating new variables at runtime, to make a Maxis-like simulation game, was like pulling teeth.
> in April, it all came to a head: I needed a new game engine to build the kinds of games I wanted to make. My years of working with Unity and Godot and RPG Maker and Game Maker had taught me that they were the wrong toolkits for the job. There just weren't any game toolkits out there for someone who wanted to build 2D games that did all of their thinking at runtime. C# supported the concept of injecting scripts and variables at runtime, but it just isn't easy to do in any existing engine. I needed something new.
> that's how exigy got started last April: a software/shareware design toolkit born out of frustration.
! nine months later, exigy is getting ready for its first pre-alpha, and I need a place where users can submit bugs, suggest design ideas, and commisserate with one another.
! what if an exigy community was the first dry run of tomo?
? functions an exigy community might need:
       * an easy way of sharing XGY projects
       * a wiki-like area for updating the runtime documentation
       * discussion groups
       * a place to submit bug reports
       * a way of distributing new builds and news about development
? but what kind of software already does all of the above. it's a big ask to cover all of those bases. the answer, as it turns out, is one that we've known about for over 40 years: a Bulletin Board System or BBS.
! for decades I've wanted to run a BBS again, after brief love affairs with running ANSI-based boards like en.wikipedia.org/wiki/Renegade_(BBS)>Renegade, iniquitybbs.com>iNiQUiTY and Oblivion/2.
* while terminal based BBSes have a wonderful ANSI aesthetic, they don't have the functionality I'd want: very few people want to load up a terminal program and navigate via keyboard-driven text menus, and deal with file transfer protocols, just to update their software. navigating messaging conferences was similarly a huge pain in the ass. what about inter-BBS message sharing? sure, we have FidoNet and a host of other software packages that can do that, but the barriers to entry for just setting that up are huge.
> tomo, which is PHP/HTML/CSS all the way down (including the NNTP server!), could be re-designed to handle all of the jobs a traditional ANSI BBS would do, BUT instead using a mouse-driven point and click interface. best of both worlds.
> want your tomo shard to look like a FirstClass BBS? just re-skin it with Macintosh System 7 window graphics and Chicago font. want it to look like an old school ANSI BBS? re-skin it using your PabloDraw ANSI menus and a MS-DOS/IBM 437 font.
> want your tomo shard to share messaging conferences with other tomo shards on tomoNet? just turn on Global mode and set it to tomoNet.
> don't want to participate in tomoNet and run your shard as a standalone island? don't turn on Global mode.
> want to form your own archipelago of shards that isn't on tomoNet? just add a list of friendly shards, and set Global mode to your personal list.
> only need the NNTP server, and don't want to give your users a web interface? just turn off the WWW portal.
> in other words: tomo is becoming a networkable bulletin board system, with every feature you'd expect from a BBS, using NNTP and HTTP as the core protocols instead of Telnet, and a mouse and keyboard instead of keyboard-only.
> this means that i'm restarting development on tomo as of this week. i'm going to focus on re-designing the front end/web interface to support the kinds of file areas, messaging areas, wikis, and posting capabilities we need.
.............................

* this week has been a bit of pause on coding to think about how tomo might differentiate itself from the concept of "social media", which i've become disaffected with over the past ten years.
* tomo is, at its core, a collection of discussion forums/groups/rooms, browsable with any NNTP client. NNTP is a fundamental aspect of the server that will never change.
? but within that constraint, there are a ton of opportunities for enhancements and customizations in the client interface that can make it a lot more fun, interesting and usable.
* my experience in user created online worlds comes mainly from online services of the 80s and 90s. Prodigy and CompuServe were my first two interactive online services. you could chat with other human beings using a "room" metaphor. BBSes were another variation upon this theme, with a smaller userbase and access to more online games.
* MUDs came along later for me, thanks to university Internet access in the early 90s. while I did not appreciate this at the time, many MUDs allowed users to customize their characters, add monsters, and even create rooms of their own using scripting languages.
* and then, in 1996, i was invited to join a little MMORPG called Furcadia. It was a graphical MUD... players were free to use the map editor and scripting language to create their own rooms called "Dreams". Each Dream had a portal to it from the starting area of the game, and stepping into it would teleport you to the person's Dream, like following a hyperlink. Dreams were completely the creation of the dreamer, and walking into one meant you were, effectively, standing in someone else's home as an invited guest. a Dream was an instance, separate from the shared world of the game, yet linked via a hub-spoke design. if there was an implicit spatial relationship with Dreams in Furcadia, it was like the "End of Time" area in Chrono Trigger (SFC/SNES, 1995), with an array of labelled teleporters to step onto and magically re-appear elsewhere. there were no limits on the number of Dreams that players could create, so there was no limit on the amount of virtual space allotted to players.
* then Ultima Online along, and adapted that same formula in subtle ways. players could build homes and decorate them, but no longer via a tile editor. houses and rooms were pre-fabricated by the game's artists to suit a particular medieval aesthetic, and could be stamped on to the game map by purchasing a deed. in UO, one did not teleport to visit a home - they simply stepped through the doorway, because each house existed in the same shared world. this was a huge change to our implicit spatial relationship: home ownership and personalization suddenly existed all within the same level playing field, and that field had a limited geography. there was only so much space to go around, making space itself a scarce resource. players began to fight for vacant land, in a cruel mirroring of medievalism. this had a second unintended consequence: because home ownership was a major means for self-expression and customization, those without homes had fewer opportunities to make the world their own.
* EverQuest and World of WarCraft took this limitation of player creative freedom to their logical end, and constrained all player behaviour to costuming and player statistics. it was no longer possible to own anything beyond the meagre possessions in your pack, and even then, those could not be dropped on the ground. your character was effectively a car that you could paint and put a nice spoiler on, and you lived in your car. user-created worlds were dead, and amusement parks were in.
! reddit, facebook, myspace, discord and other massive online services relied upon the stripped-down model of the amusement park, which was easier to police and design, because opportunities for user self-expression were so extremely constrained. old reddit allowed users to customize a subreddit's CSS. myspace allowed custom HTML and inline styles. discord allows for custom emoji. facebook - well, changing a few page labels. by this point the concept of a creative user is so stripped to the bones that the only real opportunities for personal expression is via what you say, and how you say it.
? so the question is: can tomo do something better with its architecture by allowing users to be creative people, to take pride in their self-created spaces, and encourage others to treat those spaces with respect?
? what kind of spatial metaphor would make this possible? i picked the domain tomo.city for a very specific reason: i thought about each tomo discussion group as a little izakaya you might find in a quiet hidden alley off the main streets of Tokyo. you step inside, and find either a collection of strangers who look up, surprised to see a new face... or a tightly huddled group of friends who look up and smile to see a familiar one.
> there is no word in the english language that adequately expresses this spatial peculiarity of urban Japanese life. the word "room", or "discussion group" or "forum" does not capture the intimacy and the ubiquity of the izakaya.
! each discussion group owner/moderator is like the owner-bartender of a tiny izakaya: picking the particular alley it can be found, responsible for the well-being of their patrons, the decorations on the wall, and for setting the tone of the place the moment someone new steps in.
.............................

* a few days ago i asked people what they thought about the prospect of having each tomo shard associated with a geographical locale. the question was born from my memory of "meetups" and "user-meets" of the 1980s & 1990s BBS era. in those days, users would spontaneously get together as a group at cafés, homes, public parks, for BBQ's, coffee or pizza. in-person meetups created a sense of locality and kinship for people who otherwise only shared an online hobby.
* thinking out loud: it's not so much that i think that user meetups were life-changing aspects of BBSes. it's more that i liked how close-knit users became through the personal interactions it allowed for. for as much globalism as the world wide web and internet gave us, it took away equal parts a sense of locality.
* creating those same opportunities for closeness in the public space of the modern internet sounds like a challenge that could be partly supported by interesting social architecture and design choices on tomo
? obviously, i have no real answers yet. the people who answered the question were equally flummoxed, and the overall response was "please for the love of christ don't make your discussion groups turn out like my town/city's local facebook groups. they're toxic wastelands." trust me, that's the last thing i want for tomonet. :D
! one surprising response was from dfug who suggested that allowing for strong customization provided a sense of culture for online communities. dfug writes:
       

It feels like interface customization plays a huge part in forming online communities with their own cultures; Examples I can think of would be the CSS modding of old reddit, or server mods/custom web motds for game servers?

       

That kind of stuff helps it feel like a second "home" of sorts with its own personality, I wager. There kind of was a similar thing with BBSes and their homebrew/customized server software, asciiart motds, etc

       
! user-created spaces are something i've thought about on-and-off for the past twenty five years, since i first played one of the world's first social MMORPG's called Furcadia in the mid-90's. i'm going to save those design thoughts for another post, but here's the gist:
       * people LOVE customizing their own chat spaces, and allowing your users to pick the colours of the walls, set the tables and chairs in the way they prefer, and re-arrange the wall art goes a long way towards providing people with a sense of pride and personality in their discussion space. needless to say, i'm taking this design recommendation very seriously, and *some* degree of customizability will appear in a future tomo release.
.............................

* this past ten days have been a blur of constant back-end and front-end coding. i've managed to implement the vast majority of security and permissions systems that i wanted for the tomo front end.
* now administrators can add/delete users, create custom roles for those users, and even bulk delete their posts.
? what kinds of moderation tools would you like to see, aside from the ability to delete a user's posts?
! there's a major change coming upstream from RSL-core: after some discussion, Retro Guy is adding site-to-site encrypted private messaging. This is one of the major core features I desired for Tomo from the beginning, and honestly, I don't have the experience with cryptography to write it from scratch. Retro Guy took on that job, and I'm very excited to see it go through.
? why does this matter right now? as of now, all private messages can be passed within a single tomo shard. there is no "global" messaging system across tomo shards. being able to privately message people on a separate tomo shard is a critical, core, feature. i'm beyond excited that Retro Guy is handling this.
* we're getting close to a public pre-alpha. fwiw, i believe i will launch the demo before we get encrypted private messaging set up.
* this week's job is going to spin up a second tomo shard, and test how well the peer-to-peer network runs. once i've chewed a few bugs out of that, we'll be in good shape for a public pre-alpha.
? one of the major design questions i have involves dealing with designing a front-end for the group-level moderation. right now, the entire permissions system is based on global permissions: e.g. once you have 'delete post' permissions added, you can delete any post from any group. obviously this won't work well for a reddit-style groups system. so i'm working on rewriting the permissions system for something a little more flexible.
.............................

* the greater part of the past week has been spent on writing new core functionality for tomo. it now has a basic RBAC (Role-Based Access Control) system for managing who-gets-to-do-what.
* now tomo admins can organize their shards however they want:
       * public shards that allow anyone with an account to read and post
       * super-closed shards that only allow users to post in certain groups
       * create moderator roles so mods can delete user posts
       * create co-sysop/co-admin roles so someone else can add/drop groups
! there's something crazy enjoyable about writing something from scratch. the tendency these days is to take someone else's library, inject it into a project, with a couple of minor tweaks.
* aside from relying very heavily upon RS-Light, I'm really trying to rewrite it as its own unique project.
* i'm trying to keep tomo as what I call "RSL-Core" compatible. that means that any tomo shard should be able to peer with a Rocksolid-Light server without problems. why? because tomo owes its existence to "Retro Guy"'s RSL project :)
* two weeks of programming in PHP has really given me an appreciation for how under-appreciated it is as a web development tool. the entire world moved on to Ruby, with good reasons i'm sure. but the fact that i can write an entire php script in under a minute, and have it blend seamlessly with my front-end, is incredible in 2023.
! one of the major core values i'm preserving for tomo is backward-compatibility with any nntp newsreader. i want to be able to read tomonet posts from my 1992 IBM PS/1 running Forté Free Agent, or my 2000 Nec MobilePro running Windows CE. these wonderful old beasts are still useful, or should be useful. will 99.9% of tomo users care about that? hell no. but there's that 0.1% part of the population that wants to login from their VT-100 terminal and write fanfic about some obscure eastern european sci-fi novel that existed in 1976 on tomonet.books.scifi.fanfic, and i want them to be able to do that.
.............................

* after hmming and hawing for a few minutes, i reached out to tldr.nettime.org/@tomjennings>@tomjennings for some advice on dealing with network architecture. (tom's the main architect of FidoNet, along with vital contributions from ben baker)

? i wanted to know how to deal with name collisions on the network. did fidonet care about duplicate echomail conference names? what did it do if two people created the same conference on other ends of the planet, and then tried to sync with one another? whose version of the echomail conference is canonical?

> he got back to me within 30 minutes. jesus, i love mastodon:
       

Oh boy. First, caveat, my memories of this stuff are of course old, and memory being what it is, drift. Also, when I did nodelists, up to the 100-node point!, I did them by HAND with pmate. Nodelist creation was taken over by St Louis. tbh I have no idea how they handled names.

       

But fidoNet had one absolute built-in guarantee: unique phone numbers. So four thousand CAT BBS could be unique. Can't name collision be left as a social problem? eg. just let their be (N) tomonet.pets.cat entities exist? And have their members sort it out?

> okay, i seriously hadn't thought of that. maybe i'm overcomplicating things. who cares if the group names collide? what would the nntp server do if it ran into another server trying to send messages from the same-named group? it would just merge them in! (assumption verified later by @lpbkdotnet)

> i REALLY like the idea of "why not let the users figure it out?" this is one of those massively underrated lessons i learned (apparently not enough!) from raph koster and rich vogel's Ultima Online post-mortem gdc talk. letting players figure out social solutions to technical and political problems in the game was a major part of what made UO unique.

> tom continues:
       

The idea (never even discussed, all out of my hands by this point) was to create a conference called NODELIST, and that conference's messages were all nodelist fragments that BBSs could build a nodelist from. If you're in the US and don't care about direct dialing EU, don't download those fragments.

       

But net search for "FidoNet nodelist compilation" and you'll stumble on makeNL. That name might be mine; but probably Ben Baker's. It was long ago. I don't have a filename beginning with "makenl" on my computer so probably Ben's.

       
! right off the bat this got me thinking: what if we did two things to ensure that new tomo shards could get off the ground and have at least one peer:

       * provide a live text file, available at tomo.city, always broadcasting a few peers over http/https
       * provide a single group, like tomo.peers, whose only job is to accept posts from other servers, advertising peer availability.
       

here's a thing: after I relinquished control, a lot of the people who took over centralized a lot of stuff. Not out of bad intent (though there were a few....) but out of lack of overarching theory. I was pretty open with my idea, but I didn't have it together enough to know how to ... guide or induce them to continue. And it all moved so damn fast.

? i ended up having to go mow the lawn to think this one over. despite my utter disdain for geopolitics, technical limitations which lead to centralization have huge repercussions. one of the reasons fidonet came apart at the seams (politically) was because of regionalism and power. centralized hubs, master nodes, zones, regional adminstrators... all of that top-down hierarchization was detrimental in the end.

       ! it seems like now would be a damned great time to work out the "overarching theory" necessary to pull off REAL decentralization.
       ? what lessons can we learn from bit torrent, gnutella, activitypub?
.............................

? asked mastodon users about whether they preferred usenet-style
hierarchies or a reddit-style flat structure. interesting mix of replies:

       > usenet hierarchies provide logical descriptive structure
       
       > digging through nested branches sucks
       
       * strong search capabilities may solve the hierarchy-flat problem
       
       > usenet history: alt.pave.the.earth mocking alt.save.the.earth
       
       - i fucking hate hate hate host@user/post URLs used by mstdn/lemmy/kbin
       
       > locality is important to users. uk.soc. and de. are separate cultures, and prefer to have their own regional hierarchies
       
       ? should group naming conventions be left as a social problem?
       
       + rachel stantz suggested to limit total tomo.group.names to 72 chars, so they fit on a single 80x24 screen. seems like a nice number.
       
       + one solution is to allow users to merge/delete/move groups e.g. tomo.pets.cats.help decides they fit better into the tomo.animals hierarchy. what if they could move the entire group over by having the group owner submit a rename request?
       
       + a few people suggested a "follow every group below the selected level of the hierarchy" option. e.g. you can subscribe to tomo.cats.* .. very cool idea!
       
       + proposed naming structure: tomonetwork.group.subgroup e.g. tomo.pets.cats
       
       ! i realized that this network could operating more like the Gnutella protocol, and actively broadcast peer lists. this would make it extremely simple for new servers to join the network. they would only need the name of one network server (e.g. tomo.city) to join
       
       * people really like browsing hierarchies. it's almost like walking around in a video store, checking out the different genres. i like that idea too. we can solve the subreddit discoverability problem by providing a hierarchy interface with strong search.
       
       ? steve-o stonebreaker suggested allowing symlinking/aliasing between group names: tomo.games.starcraft and tomo.scifi.videogames.starcraft both end up in the same group.
       
       ! shannon clark made a good point: the major problem worth solving is whether you need to create a new group, or use an existing one. this is best solved with a great name search BEFORE you create.
       
       + add a multi-step process to create_groups.php: you type in the general topic, and it filters out existing groups. if you see that one of those groups suits your needs, you join it instead of creating a new one.

.............................

* Syber Shock on usenet.news.software.nntp recommended checking out "rocksolid-light".. an nntp-forum package that combines both a built-in nntp server back-end, and a php-based web front-end. looks slick

? rs-light doesn't seem to have a full NNTP command set, but it has enough of the commands to work fine i think

* rs-light feels like a bbs. i like this even more than "nntp-forum"

- no inn2? that's a fucking win as far as i'm concerned

* @profoundlynerdy@bitbang.social is excited about modernizing UUCP.
       * seems to have similar ideas about re-purposing nntp, but has different
        goals in mind. we'll stay in touch.
.............................

> been working with inn2 and nntp-forum, and managed to get the front-end (nntp-forum) talking with the back-end inn2 server.

> cannot figure out why tls/ssl isn't working for inn2. it connects, then just waits there. cannot starttls or anything

+ mentioned my first goals for this weird "reddit-like but not reddit, usenet-like but not usenet" network of bulletin boards:
       + let users create their own discussion groups (.pets.cats.voids)
       + let superusers create their own hierarchies (.pets.cats)
       + create/delete/modify user accounts
       + moderation tools: kick/ban
       + peering between servers on the same network
       ? activitypub integration?
.............................

* i found out that news.grc.com exists today. it's a private nntp server for Gibson Research Tools (maker of SpinRite). steve gibson uses it as his message board & customer support gateway. he says it works better than e-mail, because it's public. neat!

* posted a message on grc.news.feedback, asking steve about grc's back-end implementation. inn2?
       

Hi Steve,A bunch of folks over on Mastodon are impressed with your non-Usenet NNTP implementation. We'd like to do something similar - a private non-Usenet NNTP server (and in our case, add peering between servers). We were hoping you could describe a little bit about how grc's news server works. Is the server software based on INN, or something else publicly available? I noticed that you also added (user-level) message deletion and (mod-level) thread locking, which are pretty fantastic moderation tools! The web UI for read-only newsgroups is also really nice - I imagine that one is custom coded?

* steve got back to me right away!
       

It is based on INN. I've edited the INN source to do two things: In order to qualify to submit a posting and thus move out of read-only mode, a user's logon username and password MUST be identical. Since both are completely private and never appear in any posting content, there's no risk to the user. And since usernames are visible in newsreader UI's, this helps them remember their passwords, since they will be the same.

       

This simple measure solves the entire issue of both automated and casual troll postings. Without knowing that semi-secret, postings are rejected by the server. (This is checked for by a PERL script that's invoked by NNRPD, the newsreader interface process. PERL and PYTHON hooks are supported by both the INND and NNRPD processes.)

* steve's post gave me a lot of ideas and was super encouraging. sometimes it's surprising how passionate and helpful folks are, despite 30+ years of internet experience telling me different.

+ rachel stantz suggested hiding users' email addresses by default in the nntp headers. that sounds like a damned fine suggestion to me
.............................

* so this is the day it all began. i barfed out a mastodon post lamenting the loss of USENET.
       

i can't believe i'm saying this - i just realized that i want #usenet groups back. to clarify - I'd like to see a usenet back, minus the "big 8" cabal, minus 200TB / day binaries, and all of the ugly crap we've seen since the 80s. i'd like to see something like a new usenet offering activitypub integration, minimal data transfer (text-only), and easy group management.

! a few hours later, the lamentation crystallized a bit more, and became the proposal for a design:
       

thinking out loud: what if we built a peer-to-peer closed network of NNTP servers? not usenet and not subject to its policies, spam or massive binary data. a wholly separate NNTP network with its own policies, hierarchies and groups. consider this an open discussion thread for anyone who has thoughts on building a separate, yet technically compatible-to-usenet, nntp network.

? what have i gotten myself into? i can't stop reading about tiny private nntp servers
.............................