
Next steps for Gmane - sohkamyung
http://home.gmane.org/2016/08/29/next-steps-gmane/
======
cm3
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.

~~~
dcosson
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.

~~~
zeveb
> block quote formatted so it takes mental effort to even figure out what's
> the previous message and what's the reply

You think it takes mental effort to read proper quotes, e.g. in
[https://www.postgresql.org/message-
id/CANP8%2BjKvbe2jwOzUMGo...](https://www.postgresql.org/message-
id/CANP8%2BjKvbe2jwOzUMGotX7ajzh-
qQ7%2Be2AT2qoU_ktAvZQN%2BPg%40mail.gmail.com)?

That's proper quoting style. It's incredibly readable, much more than the top-
posting scourge we must deal with on so many mailing lists.

------
athenot
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.

~~~
ronjouch
> _" 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/](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?

~~~
niftich
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.

[1] [https://github.com/for-GET/http-decision-diagram](https://github.com/for-
GET/http-decision-diagram)

~~~
pjmlp
Yet HTTP 2.0 is a bit like TCP on TCP, given its new binary only format.

~~~
niftich
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).

[1]
[https://news.ycombinator.com/item?id=9548138](https://news.ycombinator.com/item?id=9548138)

[2] [https://tools.ietf.org/html/draft-hamilton-early-
deployment-...](https://tools.ietf.org/html/draft-hamilton-early-deployment-
quic-00#section-10)

~~~
pjmlp
I sadly know QUIC.

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.

------
guelo
> I petitioned some of our directors

What directors? I couldn't figure out from the post who Martin Danko is or who
he works for.

~~~
mcbridematt
The about page on gmane.org has been updated, the new owner is hosting company
Yomura (Delimiter)

[http://gmane.org/about/](http://gmane.org/about/)

~~~
wtbob
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 …

~~~
sevensor
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.

------
michaelhoffman
Thanks so much! Gmane is such a great resource for the world.

And thanks again to Lars for his years of service.

------
paulrosenzweig
For the uninitiated, what is Gmane? From their home page it looks like it's
similar to Google Groups. Is that a fair assessment?

~~~
niftich
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.

See the 'About' page [1].

[1] [http://gmane.org/about/](http://gmane.org/about/)

------
julenx
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/](http://markmail.org/) for a while as a gateway to many
mailing lists.

~~~
majewsky
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.

------
cyphar
Is there a plan to make the server code free software and publicly available?
It would help avoid this situation in the future:

> As part of the agreement, we have received the INN spool with all the
> articles but none of the code that drives the site.

~~~
majewsky
Better get the spool without the code than the code without the spool.

~~~
cyphar
I was talking about the new code being written so if a similar situation
happens in the future we don't need to go through another rewrite of gmane.

------
0xCMP
I never use Gmane, but I'm happy to see that projects like this find people to
keep them going.

------
cm3
I assume the old links to threads/posts will be alive again soon.

~~~
jevinskie
Whoah! It seems like they are!
[http://article.gmane.org/gmane.comp.compilers.llvm.devel/881...](http://article.gmane.org/gmane.comp.compilers.llvm.devel/88108)

------
rurban
lars posted some of his gmane backend code at his github, but who knows common
lisp nowadays?

[https://github.com/larsmagne/reticule](https://github.com/larsmagne/reticule)
for the NNTP gateway, gwene (in perl) for the rss parts.

------
joe563323
THis is really great news.

------
lowglow
Any way we can get Gmane up on Baqqer so we can donate/support operations in
some way/form?

~~~
citruspi
\- Founder of Baqqer

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.

~~~
lowglow
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.

~~~
1029109101
Totally awesome, a true philanthropist.

~~~
lowglow
I can't tell if you're being facetious. :) What more can I offer than time,
money, and services to help facilitate their endeavor?

~~~
voidz
You're doing a good job. Ignore the cynics.

~~~
lowglow
Thanks! :)

