Google Groups ending support for Usenet

It should be possible to have other things built on top of the protocol. The protocol is a store-and-forward broadcast system, and is mostly agnostic to what goes in the packets, although if you want to add a group, each server operator has to agree to carry it, and they can have server-specific restrictions on things like message sizes, dropping messages outside the limits, so it isn't reliable. If you wanted to make a Usenet group simulating Reddit, you could easily pass votes through the system. Clients would have to interpret them, so you'd have to write your own client.

It's tolerant of spam as long as it isn't extremely excessive. There was talk of de-peering Google due to a large volume of spam, before Google made the decision itself, but most groups are about half spam besides that. The low volume of actual users contributes to this.

There's a group, I think news.admin.peering, for requesting your own server to be connected to the network. I see many successful requests from various people in the group's history. The network is fully decentralized, so being connected is reliant on at least one other person being willing to connect to you.

Basic protocols such as NNTP and IRC have the benefit of being stable, small (running a Usenet server on an OpenWRT router with additional writeable storage would be doable, running a Fediverse instance not so much), and being relatively client-independent and even protocol-flexible. NNTP <-> SMTP gateways are, for example, A Thing, and people can participate in such newsgroups from either Usenet or email clients. Similarly Web gateways to either NNTP or SMTP systems.

The flipside is that the underlying protocols are also simple and absent some additional tooling lack much of what it is that people have come to expect from more recent messaging systems:

- Mobile device access. That's probably the big one, though I'd argue that for useful discussion you're better off eliminating mobile use. I've commented that losing a keyboard and being forced to a small screen cuts my effective IQ by half, and that quality of discussion on public systems also seems strongly negatively affected by mobile use. Read-only access might be a compromise, with some "I have something to say but will wait until I can access a Real Computer" might be an option. Android + Termux + Bluetooth keyboard meets my minimums as "real computer", FWIW.

- Formatted text, usually a flavour of Markdown or some "smart editor" for normies. Then again, we seem to survive with much less than that on HN.

- Images. That's the principle feature NNTP lacks natively, though they can be shoehorned in via uuencoded posts. Along with audio and video, the ability to create multimedia posts (popular, occasionally useful, terribly abused) might be an objection raised by many.

- Third-party clients. The great strength/weakness of NNTP and SMTP are that neither are locked to a single client, or Web client (though the latter is available). Having a specific tailored client program (tin, slrn, Emacs, pan, etc.) is useful because the features of the platform are strongly supported by those clients. Downside is Yet Another Piece of Software to install and train on. In the mobile world apps have been breaking the notion of everything-in-the-browser, though often bringing along their own set of issues, most notably surveillance, but also general issues of design, UI/UX, maintenance, security, and abandonment.

The initial question addressed could and the answer really is "trivially", from a technical level.

Yours is "should", and as I'd hinted in my initial response, that's far more social and up for debate (as we're doing here).

But at least you're demonstrating a exception to Ian Malcolm's could/should criticism.

There were some bad ideas in the beginning, FTP as an example of several of those

The textual discussion network may as well be its own wholly separate network. I only know of Eternal September, but I'm sure there are other servers.

And hope the provider actually carries text groups and not only pirate movie groups.

I get the frustration, I really do. It makes sense that different Google technologies should work with each other like in this case, but I can see why this sort of thing slips through the cracks when the teams are so far removed from each other.

Regarding Bazel's ability to do this, I can't say for sure, but I see a common pattern in Bazel usage outside of Google where users expect it to work at a higher level than it does. At a fundamental level if you can do it on the command line by running commands and moving files around, then Bazel can do it (hermetically, reproducibly, etc). Big Bazel deployments build up a lot of build definitions that handle all these things and abstract away the details, and these may be what's missing.

Anecdotally, I work on a very large Android app, and it's all built with Bazel rules that are many layers deep of customisation. At the bottom somewhere is a `java_binary` rule or something like that from Bazel itself, but there's a lot of customisation to make it work for us. It sounds like this would be necessary to get Firebase working. Ultimately though if Xcode can build it, Bazel can script it.

As for Cocoapods/SPM etc, the reason I said these were at odds with the Bazel process is because Bazel is designed for a world without package managers where you just have all the code in your monorepo with the appropriate BUILD files, because this is how Google works. It sounds like there is tooling to work around this and get the code into the Bazel cache, but it's unlikely that automatically generating BUILD files is always going to get it right.