> 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 Renegade, 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 @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
.............................