As a loophole to the shenanigans regarding age restricted “website” legislation in western countries, I suspect the reverse to be desirable. IMAP, POP3 and NNTPS are not website protocols and could be exempt from the legislation. Simply making a better, more streamlined “mail” interface could be just what the doctor ordered, especially if offline viewing becomes necessary but this is getting crazy.
If nobody has done so, a POP3 gateway for the ReST interface of the Discord server could be just the ticket! I’ve never done one before and I think it may be time to begin!
I agree with everything except the last sentence.
Non-web protocols are better not only for the reason of age restriction nonsense,but also because the web has become too slow and bloated,there’s too much ads,tracking and big tech bullshit,it just isn’t fun anymore.
That’s why I started a native Usenet newsreader project.
I think that the Usenet could be exactly the place we’re looking for,a big network of independent servers that are difficult to restrict or censor all at once.
Why do we need to have the latest browser and load tons of Javascript just to consume content that is 95% plain text (looking at you,Discourse).
NNTP/Usenet already solved that problem in a much more elegant way: The client is a native application,you only load the content using a standardized protocol.
The Usenet can also provide ways to effectively circumvent the age restriction nonsense even if you’re living in a jurisdiction where it applies: It needs only one Usenet server that operates a .onion domain,and you can access the whole network through it - That’s the point of decentralization.
But please,just let the tracking nightmare that is Discord and even demands face scans or passports die a fast death.
No need to make a nice standardized gateway for a awful proprietary and centralized walled-garden that doesn’t care about its users.
We already have non-web protocols for chat,namely IRC and XMPP,we already have native clients for both and Haiku has a active community over there (primarily IRC,but it can be accessed also from XMPP and Matrix).
By the way,both standards support a lot more features than what we have in the Haiku-native clients right now,so you could help by improving Vision (IRC) or Renga (XMPP) if you want a more modern/feature-rich experience.
I want to install an NNTPS (encrypted NNTP) server on my old ARM7 Cubox using Enigma BBS under a 2-Clause BSD licnsed source code but the database runs on 64-bit Postgres. I just signed up for the $5 a month cheapie rate on PlanetScale.com that hosts PostgresSQL online. The reason it’s cheap is that all the non-database-related static stuff has to be hosted on another server somewhere else, like GitHub Pages or https://codeberg.page/ (for pennies on the dollar hosting rates, by comparison).
I noticed today that the Enigma BBS link above is hosted on GitHub pages already and probably only has the database on PlanetScale also! It was their own advice on the website do do so but even a 3-node replica set plan on PlanetScale is only $15 USD monthly and each node can be in different countires! Fore even more security, I am considering making another on-site server also have replica set status to the cloud version to make sure that if PlanetScale does us dirty then we have a full duplicate version locally to migrate.
Distributed Networking?
I am considering just how obscenely internationally distributed just such a network can be! Database distributed between two different cloud providers for redundancy, static pages on both GitHub Pages AND CodeBerg Pages to have presence in both USA and Germany, for added duplication and have all of them mutually run replica sets from a home-brew server that is a backup to all the rest and a distrubution channel besides!
I see that the NameCheap.com DNS provider supports DDNS so adapting that with an edge server in some other country yet but hosting the static WebAssembly payloads to download from, in Khazachstan or China so the likelihood of Western nations figuring out how to keep my fallback coordination from redirecting all of the subdomains of two different DNS providers in sync with one another from another undisclosed location yet… This is going to be fun!
Where did you see that Enigma BBS supports the NNTP(S) protocol?
On the features page,I can’t see it mentioned: Features | ENiGMA½ BBS Software
Also,I really doubt that a static site host and a database will be enough to run that thing.
The user should never connect directly to the database,that would allow me to edit any random message or user account,or even delete everything.
You will need at least some small vServer that hosts the Enigma Node.JS app that connects to the database and provides access to the user through SSH (the Terminal BBS) or a web view.
nntp-server · GitHub Topics · GitHub is a tag on GitHub that that Enigma BBS lists plus others. I haven’t found the docs for it yet but it is essential to my plans to not only implement this but not use any web-protocol frontends (http or https).
@PulkoMandy see above. Most “mailing lists” have a user-facing “control panel” viewed through a web-browser. To be an effective replacement for internet accesses legally defined as “websites” with content and age requrements, those need to migrate to new software.
Why would I allow a user access to the database? I wouldn’t!
As long as I use a database as a backend, it’s just an abstraction. The user doesn’t see it or even know it is there except that it works.
There is a Docker image just for that. I might use my little 32-bit setup as a server, independent of the static page if needed. (If Docker support on 32-bit systems is absent I can implement it without docker on my little Debian install.)
Oh right,I should learn reading
I only saw that you bought a PostgreSQL and that you’re talking about Github pages and thought that alone can’t work,haven’t seen your ARM7 Cubox in the post first.
gopher support was hacky in the netservices kit to begin with. Haikuwebkit no longer uses the netservices kit… But seeing as gopher is super simple, why not improve the gopher support in netservices to remove the wierd “and then translate the response to html” part and make a native client instead?
Because it’s better to use it in a browser. Gopher protocol was available in WebPositive and got discontinued. Wrong move in my opinion. This decision should be revised.
no, i think it should be seperate, it would be weird in my opinion (in looks) as gopher is really different from html, so browsers like lynx, links, or kristall are good
Why not? If sonmeone is interested in Gopher support and submits a clean patch, I don’t see why WebPositive shouldn’t include it.
Making a clean patch that somehow fits Gopher properly side by side with WebKit is going to be… interesting, and much more complicated than making a separate app. But it’s not impossible.
I doubt anyone really cares about Gopher enough to do the actual work, but if you do, prove me wrong on that
I don’t see how this is even possible without either implementing gopher support in webkit or bypassing webkit in WebPositibe.
The first aproach seems infeasible to me, and to the second aproach I would heavily object.
If you are going to take WebPositives code anyway… why not just use it for gopher, but leave the webkit based version alone? From an architecture standpoint it just makes no sense for me to shove gopher into webpositive, and from a UI perspective it is also “icky”.
In any case, the request was to “bring back” the gopher support from before, which we won’t do, as we use curl now.
There was an embedded proxy that converted the gopher replies into html. The browser and WebKit engine never used gopher directly, it was done from under their feet.
An application that can handle multiple protocols and content types seems like a good idea to me. So if you have a gopher:// link in a webpage, you can click it and it just opens. Same as we do with FTP.
Ok, sure, then it isn’t strictly a “web” browser anymore. It’s more than that. But from a user experience point of view, this seems quite reasonable to me. The underlying protocols and document types shouldn’t matter. If it’s a hyperlink, you can click it and it opens, you can bookmark it, you can use back/forward to navigate, you can find it back in your history.
On the implementation side, sure, it won’t be so simple. Personally I have no interest in attempting it. I can provide some hints at the problems to expect, for example, the back/forward list is managed by WebKit, which means trying to implement this separately from WebKit will raise some interesting problems. And implementing it inside WebKit means convincing webKit developers that this is something they should upstream. But, as I said, if someone else is willing to do all that work, and does it cleanly, I have no reason to put myself in their way.
