* 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
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
.............................................................................................