Date: Saturday August 05th, 2023
Time: 12:17:47 PM MST
From: @vga256
Groups: tomo.dev
Subject: the city and the izakaya
* 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.
.............................
Date: Wednesday August 02nd, 2023
Time: 12:17:47 PM MST
From: @vga256
Groups: tomo.dev
Subject: the joy of scope creep
* 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.
.............................
Date: Tuesday July 25th, 2023
Time: 12:17:47 PM MST
From: @vga256
Groups: tomo.dev
Subject: expanding the sea map
* 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.
.............................
Date: Sunday July 16th, 2023
Time: 12:17:47 PM MST
From: @vga256
Groups: tomo.dev
Subject: roles and permissions
* 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.
.............................
Date: Tuesday July 04th, 2023
Time: 12:17:47 PM MST
From: @vga256
Groups: tomo.dev
Subject: tom jennings made me think
* after hmming and hawing for a few minutes, i reached out to @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?
.............................
Date: Monday July 03rd, 2023
Time: 12:17:47 PM MST
From: @vga256
Groups: tomo.dev
Subject: mastodonites sure have opinions on usenet
? 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.

.............................
Date: Friday June 30th, 2023
Time: 12:17:47 PM MST
From: @vga256
Groups: tomo.dev
Subject: rocksolid-light might be the one true faith
* 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.
.............................
Date: Monday June 26th, 2023
Time: 12:17:47 PM MST
From: @vga256
Groups: tomo.dev
Subject: nntp-forum + inn2? what should i even call this thing?
> 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?
.............................
Date: Friday June 23rd, 2023
Time: 12:17:47 PM MST
From: @vga256
Groups: tomo.dev
Subject: steve gibson is nice, and nntp is a thing in 2023
* 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
.............................
Date: Thursday June 22nd, 2023
Time: 12:17:47 PM MST
From: @vga256
Groups: tomo.dev
Subject: what have i done
* 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
.............................