This is great, and I hope they keep the (or a) JavaScript-free interface, because that's the #1 advantage over things like Google Groups which defy any browser convention and you have to fight for usability. If I'm reading an archive of posts, I don't want a web application that tries to override the browser's controls and fails to deliver.
Interesting. While javascript heavy, google groups always gets the job done fine for me.
What I really dread is having to use something like the Postgres mailing list, which is painful with conversations split between multiple pages and block quote formatted so it takes mental effort to even figure out what's the previous message and what's the reply. I'm not familiar with gmane and am young enough not to have been a heavy newsgroup user.
And the amount of HTML, CSS, and JS it loads is disproportionate to the content, making me dread anytime I have to use it to read a thread. The asynchronous loading of content induces a painful delay in the workflow.
Agree 110% on the js-free being a huge positive. It's getting to the point where I want to revive those "thank you for not using AOL" flashing gifs and update them to try and start some kind of "no js" countertrend.
Upvoted. I don't hate JavaScript but there is no need for JavaScript on a site like that. I suggest NoScript as a way to turn on or off JS per site.
Partially offtopic. The very page at http://home.gmane.org/2016/08/29/next-steps-gmane/ is much better with JS turned off: JS loads the Raleway font which at the given size and color (#666) is too thin and not contrasted enough to be readable. I have to zoom in many times before it gets OK. The default Arial is much easier on the eyes. Raleway is not that bad on my tablet, maybe because of a higher DPI (8.4" at about 2500x1600 vs 15" at 1920x1080) or because it's AMOLED. Not bad but not good enough. Arial wins even there. With a color of #222 or darker Raleway starts the be readable, but still worse than Arial.
Google Groups seems like a proof of concept for GWT. Something someone design during a lazy friday afternoon. Except for the content, I have nothing positive to say about Google Groups. More often than not I prefer to not having a question answered, if the only solution is to use Google Groups.
This may be surprising, but Sourceforge provides plain mailman lists for projects, and that's a viable alternative to Google Groups for open source projects.
I came to Gmane back when I needed to search newsgroups (NNTP) archives, then later on, mailing lists.
Maybe I'm nostalgic but I really miss the newsgroups that focused on just the messages, and could be consumed by any client, stored offline, searched, etc.
> "Maybe I'm nostalgic but I really miss the newsgroups that focused on just the messages, and could be consumed by any client, stored offline, searched, etc."
I don't see anything nostalgic about that, there's value in the benefits you list and rightfully associate to application-layer protocols.
A few months ago I stumbled upon a good article that praised them too, over today's "HTTP for everything", but I'm sadly unable to find it in my bookmarks. Anyway; more than anything, it lauded the interoperability that comes with those protocols.
I'm sending email from Thunderbird, and can reply minutes later from my iPad, and follow-up/search my archive at work from Outlook or Mail.app. Transmission merrily talks to uTorrent or Deluge or rTorrent. My windows box reads video files from a Samba share.
What now? Apps interfaces are at worst totally obscure (Skype), or at best exchange readable but undocumented JSON/XML over HTTP(S). Put differently: had email been designed & implemented today, we would hardly enjoy the same interoperability. There seems to be little interest around designing new protocols (and maybe little help coming from languages/libraries too?). IRC v3 ( http://ircv3.net/ ) comes to mind, but it's pretty niche. Anyway, I'm ranting. Can anyone complement from experience trying to do such protocol design/implementation today and the challenges associated with it?
HTTP won out because it's the 'universal' protocol: you GET a resource, you say 'I prefer text/html but really anything is fine', the server puts bytes on the wire, it includes some metadata (headers, Content-Type), and then your user-agent interprets that Content-Type and displays the result. It's an extensibility advocate's dream. Using this and the jack-of-all-trades datatype HTML, we developed documents that link to other documents. When we were no longer okay with static pages, we hooked up programs that wrote HTML onto stdout and at the end of the day, everything just came across as a sequence of bytes. There's no formalized, official application-level logic to the HTTP state machine (although there are third-party attempts [1]).
Using these universal building blocks, we built applications where state transitions consists of GETs and POSTs. Eventually, when we wanted machine-structured data, we did XML-RPC, later codified into SOAP, before the backlash against hard-to-understand standards led to JSON being traded between server backends and client-side obfuscated, minified Javascript state machines.
Not enough people make new running-on-TCP or running-on-UDP protocols because new protocols are hard to design, they don't work with the one application where everyone spends 70+% of their time (the web browser), and they probably get blocked on a middlebox except if you use port 80 or 443 and fake being HTTP anyway. For all but very specialized use-cases, vomiting blobs of JSON (or if you want to feel extra good, some custom binary serialization format like protobuf or Thrift or Cap'nProto or MessagePack) across HTTP endpoints is pretty okay.
HTTP "won" for the reason that port 80 was open anyway on corporate firewalls, so everything was shoehorned into it - but not for purely technical reasons.
Oh absolutely [1]. But the HTTP/2 endgame is likely to re-define it in terms of a protocol over QUIC, a situation the QUIC folks are eagerly anticipating [2]. This is no surprise considering both originated at Google.
QUIC is a secure transport protocol (subsuming most of the features of TCP and TLS) that runs on top of UDP (because they wanted to craft a 'better' TCP, and the only other not-blocked-by-default transport protocol is UDP).
Since Google pushed it into Android Chrome, I cannot log-in into our customers WLAN infrastructure on Android 4.3 only with 4.4+ devices, not even by disabling it via the flags menu.
And some of our devices are on 4.3 and now need to make use of HSDA for network access.
Interestingly, Yomura Holdings have almost no presence on the Internet at all. Indeed, almost the only reference to them is on forums where people ask who they are. Very odd …
This is entirely reasonable -- one of the reasons Gmane was taken down was constant threats of litigation. Keeping it a separate business entity owned by the same holding company means that a lawsuit aimed at one won't sink the other.
Not unusual though. Many people have holding companies with the sole purpose of separating the them and their "actual" company, in case of bankruptcy. Holding companies like that seldom need an internet presence, or any presence really, they only exists to provide legal protection.
The company I work of is actually owned by a series of individual holding companies, each one hold some percentage of the shares in the operating company. The holding companies mainly exists to protect the owners from bankruptcy.
Gmane is a bi-directional gateway from Mailing Lists to NNTP (the 'Newsgroups' protocol), with some extra features like spam control, search, web interface, and RSS feeds.
It's also an archive of the above. This archive functionality is in common with Google Groups.
It might not be as complete as Gmane perhaps (I didn't stop to compare them on a feature-by-feature basis), but I have been happily using http://markmail.org/ for a while as a gateway to many mailing lists.
Markmail is great. If only they could replace their Flash-based graph by some sort of <canvas>. Also, I think Gmane has more coverage in terms of number of mailing lists.
I don't have a problem with self-promotion, but if you're more interested in supporting Gmane than in promoting Baqqer, it shouldn't really matter if the donation is via Baqqer, Gratipay, Patreon, a Bitcoin address, or even just a PayPal donation link.
We built Baqqer for this reason. I wanted to know if we could get them on there so we can actually help. I can't really help them set-up or maintain their presence on other sites, but on Baqqer I can instantly provide them with support, features, or even minimize fees if it helps. It's win-win.
Just a member of the HN community trying to help out how I can. :)
Edit: According to your resume you've been a contributor to Gratipay.
The point is not whether you're being selfless or not. You should have put a disclaimer about your involvement with Baqqer in your first post. Now the stink from hidden advertisement just covers the actual message.
