I've almost prepared the first release version of a decentralized textboard. It allows threads and replies to be shared between multiple servers, and threads are assigned to tags, rather than boards.
What kinds of features should my board have besides just these? It's still very minimalist -- a blank slate for progress!
There are multiple decentralized board projects, nobody uses them as it is because of the convenience of the web and that everyone who uses this sort of thing likes traditional BBSes.
/net/ or /iaa/ may be more interested in this sort of thing
>>1-san is tokiko, and the new default name is very fitting for his current condition.
That aside, the whole tags instead of boards things reminds me a bit of 4taba.
Does it allow for user creation of tags, or is there an preexisting list? Or, for example, can the admin of a node choose which tags he supports, and only mirror the thread contents for those specific tags? Allowing each admin to create their own tags seems like a reasonable compromise between full on user board/tag creation and predefined tags. We need more details!
...
Wait one second, decentralized textboard? Isn't that just an anonymous Usenet knockoff?
> can the admin of a node choose which tags he supports
This is the default behavior now; I worry about people misusing the tags feature or doing tag spam. Unsupported tags from remote boards are rewritten to "random" but I could also add features to filter out specific tags (eg NSFW).
> Allowing each admin to create their own tags seems like a reasonable compromise between full on user board/tag creation and predefined tags.
Bingo.
> Wait one second, decentralized textboard? Isn't that just an anonymous Usenet knockoff?
In a sense, yeah. But who really likes Google Groups? NNTPchan is definitely an inspiration in some ways, but I don't agree with all the design decisions.
If you have any thoughts like "I'd like to see..." or "I don't want to see..." that would be super useful!
>But who really likes Google Groups?
I'm trying not to be the guy who's overly harsh on someone for sharing a personal project, but this isn't really a relevant response to >>5's comment about Usenet.
If you meant "Usenet is unpleasant because you have to access it through Google Groups", then that's flat-out wrong, and missing the whole point of NNTP.
If you meant "Usenet is unpleasant because some other people somewhere access it through Google Groups", then I don't think any software is going to solve your problem, and certainly not decentralized software.
So, what you're describing really sounds a lot like NNTP. It's distributed, threaded conversations, thread classification is many-to-many form, and so on.
>>7
what's the point you're trying to make? "use nntp because it's well established?" i see your point but it's not really contributing to the discussion.
i had more fun making my own system; starting from a very minimalist and novel way of storing/sharing posts also opens the door for me to easily add features that haven't been seen in USENET or textboards previously; hence, the post.
>>6 I'd like to see tokiko in a skimpy little nazi costume again
>>8
In the OP, and later in >>4, you seem to be claiming that what you have is novel, and that you want to advance the current field of textboards/forums/BBSs/etc. That may not be your intention, but it does read that way. With that as a goal, it's completely reasonable for me (and the others in this thread) to point out prior work. The point is then "You seem to be missing significant information, without which you cannot reasonably hope to accomplish your goal: here it is".
Now it's more clear that your goal is less Napoleonic than it first appeared, and I think I understand enough to give you some responses.
- It needs a way to deal with spam, taking the decentralization into account. This is probably the hardest one, because you have to plan for it before you see examples. It's also consistently the biggest obstacle to any communication system that doesn't include some sort of manual moderation.
- Consider the killfiles of advanced usenet clients, the regex filters on 4chan, and the pretty-much nothing that we've got here. These are responses to how the clients (encouraged by the protocol) display messages. The more the user feels that they are directly receiving the message, the more control they want over what to block/ignore. The more the user feels like they are observing from outside the system, the easier it is to get by without heavy-duty filtering.
- It needs some way to deal with people who want to post images and large data content text-encoded, because nobody wants to run a node of what's advertised as a textboard only to spend 99% of their disk space on shitty base64-encoded porn.
- It needs web server interface because I'm not going to install special software just to test out a forum that I don't know if I like.
- It needs a standalone interface because browsers suck.
- Some jackass may bother you at some point about implementing ActivityPub. You'll want to have a prepared response.
- It needs some manner of passing links to past threads that humans can easily obtain and share, and use their clients to get.
> It needs a standalone interface because browsers suck.
Great point - I think I'll make a TK client.
> It needs a way to deal with spam, taking the decentralization into account.
I've put a lot of thought into this. Agree completely. My captcha solution is to just have a user captcha to whitelist their IP address and hope for the best. Can change as needed.
> It needs web server interface because I'm not going to install special software just to test out a forum that I don't know if I like.
So far it's as easy as:
"git clone whatever"
./setup (small wizard)
./run (web server running at port XYZ; fix this with nginx or whatever, I'm not your dad)
> Some jackass may bother you at some point about implementing ActivityPub. You'll want to have a prepared response.
It will have ATOM feeds, which will be connected to activitypub bots. That's about as much work as I'll put in.
thank you're for you're poast