On 28/08/2018 23:25, Michael Stone wrote:On Tue, Aug 28, 2018 at 10:24:51PM +0100, Mark Rousell wrote: Well, I expect you're not going to like me saying this but isn't expecting ISPs to do this more Usenet-style thinking? People don't expect ISPs to run forum servers or mail list servers, so why should they expect them to run NNTP servers for private discussions groups? so stop talking about 'a generic architecture of NNTP transit servers that isn't usenet but is still open to arbitrary groups and users but doesn't have any of the problems of usenet because it's carefully controlled and thus doesn't have abuse issues but isn't prohibitively resource intensive and people will set up serves and join the network because nobody likes stupid old HTTP anyway' I have at no stage advocated a "generic architecture of NNTP transit servers". I have at no stage advocated any NNTP servers being "open to arbitrary groups", other than those created by group owners. I have at no stage suggested that it wouldn't have abuse issues, only that abuse issues can be handled just as they are right now on any non-federated NNTP server, on any mail list, on any web forum, or similar. Indeed, NNTP is not prohibitively resource intensive when used as a private discussion group protocol. You got that bit right. I have at no stage suggested that people necessarily would want to set up their own servers (although in principle they could). This sort of thing is more likely to be run as a service, just as mail servers, mail list services, and web forums often are at present. And I have at no stage suggested that people don't like HTTP. What I have been talking about (since I mentioned I'll be working on NNTP) is implementing NNTP as an alternative access methodology to message resources accessible via other means as well. There's more to the project than that but this is the aspect that seem related to this thread. and instead start talking about something that's likely to be implemented: centralized NNTP gateways to the services most people will use via SMTP or HTTP, with NNTP client access to the gateway. This sounds a bit like trying to reinvent Usenet. It's not going to happen that way. You might see people create private transit servers for local access, but the number of clients using such servers instead of the primary one would suggest de minimis bandwidth savings. If anything, the private transit servers would end up like most private debian archive mirrors and consume more bandwidth than they save (because most of the transferred files never get used). And in this model, any putative "transfer efficiency of NNTP" is simply not compelling. Quite possibly. Although we've discussed the bandwidth efficiency of NNTP at excessive length, it's admittedly not the primary driving motivation for this work. But, all the same, if bandwidth efficiency is an issue then I'd say that NNTP is good for this scenario. YMMV of course, and that's fine.
Fine, so you prefer web UIs, if I understand you correctly. So the "broad client support" in question would be a web browser and that basically includes everything. Welcome to the 21st century! Except that web browsers accessing web forums in the 21st Century don't do everything. They can't. Other tools do some things better. That's rather the point. There are other tools that bring other capabilities to the table. For example, some of these tools are the NNTP and SMTP and IMAP protocols, and these can be accessed by mail clients and NNTP clients. These protocols and clients facilitate users who prefer these tools to do things like choose their own client apps, control how their UI appears, manage who they view and store data, and so on. These approaches provide way more capability and are way more flexible than any web forum's HTML UI. Earlier in this very thread, Rich Kulawiec posted this extensive list of reasons why email is a good protocol for discussion groups: [🔎] 20180809230309.GA7104@gsp.org"><https://lists.debian.org/msgid-search/[🔎] 20180809230309.GA7104@gsp.org>. These reasons also apply to NNTP. (Rich referred to Usenet in his message but I think we can read "NNTP" for "Usenet" in his message). So, as you can see, alternatives like email and NNTP access do bring capabilities that web UIs do not bring and are unlikely to bring since they are not standardised. I note, of course, that email and NNTP clients can be implemented in a web browser but this doesn't change the principle here that web forum UIs cannot provide all the services that some users prefer or require. Then, if your content is compelling enough, people will use whatever wacky REST API they need to get your content if they want to go beyond the HTML UI. Alternatively, one might prefer to just make it easy for them to access the content in a way that suits them. I'd guess that the number of people using google APIs (for example) today, whether knowingly or unknowingly, exceeds the total number of people that ever used NNTP, even if those people just don't understand how things would be better if they were using NNTP instead. I expect so. But this doesn't mean that NNTP (or email) are in any way unsuitable for the kind of scenario I've suggested and that Rich enumerated. But most people don't really care. (Yes, I've gathered by this point that your number one requirement is the ability to use an NNTP client--I'm referring to the other people.) The "other people" are, a priori, not the people targeted by a target use case that is focussed on providing NNTP access. ;-) As I said, there are other aspects to the project but the part that involves NNTP is, unsurprisingly, focused on the kinds of people who care about the kinds of things Rich Kulawiec listed. Many of them might prefer email but some of them will prefer NNTP instead. But anyway, I get that you really really like NNTP. Have fun, don't expect a lot of converts. Who necessarily wants or needs converts? This is for people who want NNTP. It's not for selling NNTP to people who don't want or need it. I should add that those who prefer email will be catered for too. As I said, alternatives, not replacements. -- Mark Rousell |