14 ms·

Why we have stopped making cool protocols like this? It seems Internet had really cool protocols back in the day and we had so many possibilities. Now it seems

Why we have stopped making cool protocols like this? It seems Internet had really cool protocols back in the day and we had so many possibilities. Now it seems we are stuck with HTTP. Not saying HTTP is bad. It just seems like we have given up on possibilities. I remember, almost a decade ago, Nokia had a mobile web server for Symbian devices which basically hosted HTTP server on the phone[0]. You could message the owner of phone directly through a URL. The request would be handled by server on phone! No one makes anything like that anymore. Everyone is just building on top of APIs and services provided by MANGA who would obviously not put any effort in such projects. [0]: https://linkdekho.in/254nl https://linkdekho.in/254nl

bambax 5y ago
This is how life works (biology). At every "explosion" many different solutions appear, and then fewer and fewer survive at each generation.
dec0dedab0de 5y ago
I think the reason is because corporate firewalls allow http(s) out to the internet, so everyone just used that, negating the whole point of ports in the first place.
- d0gsg0w00f 5y ago
  As someone who works in a massive corporation, this is 100% true.
kleiba 5y ago
> Why we have stopped making cool protocols like this. Eternal September and security concerns.
space_fountain 5y ago
I think two things have happened. A. People do still come up with protocols. They've just moved up a level of abstraction. Why deal with the problems http already solves if you don't need to? B. We now have big enough actors (corporations) that there is less incentive to unify, though even this isn't entirely clear cut. A lot of companies do seem to be trying to create standards for things like iot devices with some success
- Laremere 5y ago
  I think both of those are good reasons, but there's also: C. Web applications are the way most applications are used on desktop nowadays. The creator already needs to eat the cost of hosting the servers, so you might as well go for control and monetization over delving into making peer to peer work.
jll29 5y ago
Any new ideas for missing protocols, HN? More than finger, I so miss the times of USENET and the user experience of its hierarchical system of groups with threaded, text-only pull messages (I accessed it from gnus (the emacs newsreader) via my HP 9000 715 running HP-UX 9.03).
- clarkmoody 5y ago
  The Gemini protocol is an interesting re-imagining of Gopher: extremely simple text-only content, with client-side styling. Identification via client-side certs.
- azinman2 5y ago
  I’m sure you could write a Reddit client that emulates this. For better or worse, it’s the most like Usenet today.
  - layer8 5y ago
    The most important difference a Usenet-like clients brings is per-message read/unread status, which is what enables long-running threads and discussions. Without most clients (most users) supporting such read/unread tracking, you won’t have long-running discussions, which changes the whole character of the medium. Per-message read/unread status in practice requires keyboard navigation (or as an inferior alternative, paging with read/unread tracking like in web forums), which doesn’t work for mobile. The lack of read/unread tracking is also why we don’t have long-running discussions on HN. The only remaining medium with per-message read/unread tracking we currently have is mailing lists.
    - spc476 5y ago
      Not to mention kill files, allowing you to filter out people/topics/threads you don't wish to read.
      - gerikson 5y ago
        Reddit Enhancement Suite is a sort of swiss army knife killfile. Sadly I don't think it is long for this world of New Reddit.
deleted 5y ago
[deleted]
clarkmoody 5y ago
The Bitcoin wallet world is using Tor to tunnel from mobile apps back to full node software operating on home servers. Not necessarily an example of your first question, but definitely in the spirit of the HTTP server on phone.
marcosdumay 5y ago
Stupid security people set up stupid firewall rules that blocked everything else (they are mostly going away nowadays, finally). And then NAT and ISP port blocking happened too. And the phone thing was that on modern processors listening to the network is a serious battery sink.
- not2b 5y ago
  Not stupid at all: https://en.wikipedia.org/wiki/Morris_worm https://en.wikipedia.org/wiki/Morris_worm , brought to you in part by fingerd.
  - marcosdumay 5y ago
    Yeah, tunneling everything over HTTP did really solve buffer overflows.
  - wumms 5y ago
    From Wikipedia [0]: "Robert Tappan Morris is an American computer scientist and entrepreneur. He is best known for creating the Morris worm in 1988, considered the first computer worm on the Internet. 1988 – Released the Morris worm (when he was a graduate student at Cornell University) 2005 – Cofounded Y Combinator" [0] https://en.wikipedia.org/wiki/Robert_Tappan_Morris https://en.wikipedia.org/wiki/Robert_Tappan_Morris
  - DonHopkins 5y ago
    Yeah, 4.2 BSD fingerd was calling "gets" to read the name of who you were fingering into a small fixed size buffer on the stack. https://man7.org/linux/man-pages/man3/gets.3.html https://man7.org/linux/man-pages/man3/gets.3.html Chris Torek had hacked our version of fingerd (running on mimsy.umd.edu and its other Vax friends brillig, tove, and gyre) to implement logging, and while he was doing that, he noticed the fixed size buffer, and thoughtfully increased the size of the buffer a bit. Still a fixed size buffer using gets, but at least it was a big enough buffer to mitigate the attack, although the worm got in via sendmail anyway. And we had a nice log of all the attempted fingerd attacks! The sendmail attack simply sent the "DEBUG" command to sendmail, which, being enabled by default, let you right in to where you could escape to a shell. Immediately after the attack, "some random guy on the internet" suggested mitigating the sendmail DEBUG attack by editing your sendmail binary (Emacs hackers can do that easily of course, but vi losers had to suck eggs!), searching for the string "DEBUG", and replacing the "D" with a null character, thus disabling the "DEBUG" command. But unfortunately that cute little hack didn't actually disable the "DEBUG" command: it just renamed the "DEBUG" command to the "" command! Which stopped the Morris worm on purpose, but not me by accident: I found that out the day after the worm hit, when I routinely needed to check some bouncing email addresses on a mailing list I ran, so I went "telnet sun.com 80" and hit return a couple times like I usually do to clear out the telnet protocol negotiation characters, before sending an "EXPN" command. And the response to the "EXPN" command was a whole flurry of debugging information, since the second newline I sent activated debug mode by entering a blank line! So I sent a friendly email to postmaster@sun.com reporting the enormous security hole they had introduced by patching the other enormous security hole. You'd think that the Long Haired Dope Smoking Unix Wizards running the email system at sun.com wouldn't just apply random security patches from "some random guy on the internet" without thinking about the implications, but they did!
ReactiveJelly 5y ago
TLS was hard, the implementations kinda sucked, and it turned out that it was important. So we went through a dark age where "Just open a socket and have at it" couldn't fly over WAN, which means there wasn't much point doing it at all. QUIC will fix this. You can treat it like a bunch of TCP streams and UDP datagrams that are Just Encrypted. I'm thinking about doing a toy IRC knock-off with QUIC. Having TLS standardized in the transport layer means less work for the app, and having multiple streams and datagrams means that odd stuff like file transfers or even voice chat could be tacked on without opening new ports or new TCP streams. Matrix is cool and all, but I want something you can just throw down for a few friends and some bots with a shared password. Matrix homeservers are too much work for one-off. My old New Year's resolution was always "I'm finally gonna get into web dev". But I don't like web browsers. My new resolution will be "I'm gonna do web stuff, without web browsers."
- ldehaan 5y ago
  I'm building a webrtc video based dungeons and dragons app so my sister can DM for my kids and I instead of using Skype/hangouts/discord etc.. which all suck because she's in . So all that to just say I did it in Electron and it was a cinch and I'm doing mobile versions with Ionic. Both are web dev without exactly using browsers, but still using browser engines. Could be fun.
- passerby1 5y ago
  Interesting, as I went into webdev too some two years ago for a year and a half, it was a good experience. What're your pain points in browsers?
  - ReactiveJelly 5y ago
    I tried to bring some nuance to this. 10 years ago I would have said something more like "Fuck web browsers". I've toned back on the hate, but I still think they have serious shortcomings. (Not that native doesn't - Notice I said nothing about permissions and untrusted code) tl;dr: I think web browsers have a Pareto problem. Building inside a web browser is pretty all-or-nothing. Their interfaces make the most common 90% of cases easy but the other 10% of interesting niche stuff totally impossible, or too slow to be useful. Just like how old PC games would play music by triggering the CD drive's "Just play this track" feature, browsers are fine for doing super-high-level stuff exactly the way most people want to do it. But if you want to do anything with that audio other than stream it unmodified straight to the speakers, suddenly the APIs let you down. And the whole time, you're taking on some of the biggest dependencies in history. There are two companies that make full-sized web browsers. One is a non-profit constantly struggling for funding while making awful PR gaffs and being hypocrites about privacy. The other is an openly evil advertising company. Full: I've done really basic stuff, like I learned how HTTP works, I wrote a few web apps with Rust, I made a game with TypeScript and WebGL. But it just never clicked for me. My comment is missing a little context. There's basically two different niches: 1. If I want more than 2 or 3 people to use it, it has to run in a web browser. I don't mind doing WebGL and putting it on a static site. I can always do a native port if I feel like it. All the games I've made can be modelled as "Read keyboard input and run OpenGL commands", and browsers are enough for that. 2. If I want to really have fun with something, just for myself, web browsers are too big of a dependency and the restrictions are too tight. Sure, they'll get QUIC as WebTransport soon (IIRC), but I'm always gonna be limited by the dependencies. I don't like Electron out of principle. It's just so big. Native development can be awful - Big C projects are not fun to build. But Rust is striving for "Just clone and `cargo build`". What's the `cargo build` for web stuff? I have to set up TypeScript or something else to shield me from JavaScript... If I were using Electron I'd have to learn all that... I actually like local web UIs. I think because that offers flexibility. If I want to send a video stream from a browser, sure I "just" have to use WebRTC. But how do the WebRTC servers work? I haven't found satisfying documentation. What if I want to start with a webcam stream and then compose graphics into it before encoding? I know browsers have Skia, but is that exposed to me? Or is it like so many bad "Play an audio file" APIs where it breaks down as soon as I want to play a _remote_ audio file or _stream_ an audio file or _transcode_ an audio file. So (sorry for the meandering) back to my toy IRC idea. I can do that with HTTP and long-polling and it would kinda work. But it would just be a crappy Matrix clone. What I really want is to show off "Look, I think QUIC is going to bring back custom protocols, QUIC has not to come to abolish the word of TCP but to fulfill it, and here's how it looks." And I could do that with Electron, but like the "Let me do everything for you and make the 10% of niche cases impossible" API that can only play audio or send a webcam stream without any compositing, Electron presumes I'm going to have a GUI, and I'm also going to run it on the same computer. Whereas if I make the first prototype UI with curses or a local web UI, I can forward it over SSH easily or run it when a GUI isn't available. It sounds a lot like Gemini, but I think Gemini is a little misguided. It sounds like most of its proponents think that you can control a protocol by just having very noble goals. And it sounds like they are opposed to HTTP and QUIC not because the protocols are bad or even hard to implement (In the case of HTTP. QUIC actually is hard to implement), but just because bad entities use them. I think it's dangerous to believe that powerful tools are only for bad purposes. It will leave good people de-powered.
tptacek 5y ago
Finger is a silly protocol. It doesn't exist anymore because it is worse in every possible way than HTTP (or, at least, the tiny subset of compatible HTTP that replaces it). I remember when I was earlier in my career and more specialized on implementing weirdo protocols hearing that HTTP was going to replace all the existing protocols. I was appalled; it seemed absurd, like suggesting Word .DOC was going to replace all text files. But for the most part, the people saying that were right, and we are better off for it. The thing about a lot of those purpose-built protocols, even the "important" ones like DNS and most especially infrastructure stuff like SNMP, is that they are pretty dumb, the product of their time and thus, by construction, deprived of several decades of systems learning.
- pdpi 5y ago
  HTTP does a lot of things right, but it’s almost completely oblivious to the contents of requests/responses. Things like DNS also have to specify what a query looks like, and the format for the response.
- guerrilla 5y ago
  You didn't make an argument for why it's a silly protocol. You didn't make an argument for why it is worse in every possible way than HTTP. You didn't make an argument for why we're better off having replaced everything with HTTP. You didn't make any arguments about they they are "pretty dumb." Your entire post amounts to "I like HTTP" and "old stuff bad."
  - deleted 5y ago
    [deleted]
  - nextlevelwizard 5y ago
    You didn't make an argument why it isn't a silly protocol. You didn't make an argument for why it is better in any way than HTTP. You didn't make an argument why we are worse off having replaced everything with HTTP. Your entire post was stupid and had no point other than trying to be a gotcha.
tristanc 5y ago
Does adding a header-only (C++) http server to projectM’s visualizer [0] count? I added a very basic http server to switch presets from any basic web browser (including a kindle paperwhite) using a static html page. [1] It’s been great fun hosting parties and projecting visuals across the room onto an opposite wall. Then passing around a very old Android phone to go through the presets. I highly encourage others to do the same with their favorite applications it’s fairly straightforward and makes it a pleasure to use. [0] https://github.com/hashFactory/projectm https://github.com/hashFactory/projectm [1] https://github.com/hashFactory/projectm/blob/compression/src/projectM-sdl/remote.html https://github.com/hashFactory/projectm/blob/compression/src...
binwiederhier 5y ago
> You could message the owner of phone directly through a URL. The request would be handled by server on phone! I know it's not like a web server on the phone or anything, and likely questionable to mention it at all (since I made it), but I made a thing that lets you send notifications to a phone (or desktop) via curl [0] via a simple PUT or POST. It's definitely not a cool protocol since it's simple HTTP, but it's in the spirit of other Unix tools since it's just one thing to do one job. [0] https://ntfy.sh https://ntfy.sh
- Datagenerator 5y ago
  Thanks, looks useful
- dolmen 5y ago
  Missing in the FAQ: what happens when multiple clients have subscribed on a topic (ex: via SSE)? In practice (2 SSE clients): all clients are notified.
  - binwiederhier 5y ago
    Thanks for the feedback. I'll add it. Yes you are correct: It's the nature of pub-sub that all subscribers are notified if a messages arrives on a topic.
zepto 5y ago
People still do: https://mbays.sdf.org/htalkat/ https://mbays.sdf.org/htalkat/
rain1 5y ago
Gopher is still around! Get involved!
csmpltn 5y ago
It used to be the case that HTTP was used by web browsers (clients) and web servers to exchange mostly textual content. During those times, HTTP was used as a pure application-layer protocol, riding on-top of TCP (a transport-layer protocol). These days HTTP is used for everything. Server-to-Server API calls, binary data transfer, IPC, etc. A lot of these things get implemented on-top of HTTP though. HTTP is used much more as a transport-layer protocol now, an abstraction layer on-top of TCP. How did we end up here? It appears that there was an organic need to build an abstraction layer that's easier to work with than TCP, which is probably seen as too low level and much more difficult to work with. Browsers supporting HTTP out-of-the-box with AJAX made this a widespread practice. These abstractions come at high costs though.
corobo 5y ago
> Why we have stopped making cool protocols like this? Why aren't you doing it? Same reason
usb0 5y ago
I remember Nokia's MWS and if memory serves me it was powered by Apache and Python Server Pages (PSP). I thought it was crazy to port those things to mobile but somebody (reiner-keuchel.de IIRC) ported almost all open source tools to Windows Mobile long before Nokia.
aaaaaaaaaaab 5y ago
>Why we have stopped making cool protocols like this? It seems Internet had really cool protocols back in the day and we had so many possibilities. Now it seems we are stuck with HTTP. Because of corporate network firewalls. Make no mistake, they would gladly break HTTP if they could, but it became too important, so now everything has to piggyback on top of HTTP. Enforce the end-to-end principle and new protocols will flourish.

bambax 5y ago

This is how life works (biology). At every "explosion" many different solutions appear, and then fewer and fewer survive at each generation.

dec0dedab0de 5y ago

I think the reason is because corporate firewalls allow http(s) out to the internet, so everyone just used that, negating the whole point of ports in the first place.

d0gsg0w00f 5y ago
As someone who works in a massive corporation, this is 100% true.

kleiba 5y ago

> Why we have stopped making cool protocols like this. Eternal September and security concerns.

space_fountain 5y ago

I think two things have happened. A. People do still come up with protocols. They've just moved up a level of abstraction. Why deal with the problems http already solves if you don't need to? B. We now have big enough actors (corporations) that there is less incentive to unify, though even this isn't entirely clear cut. A lot of companies do seem to be trying to create standards for things like iot devices with some success

Laremere 5y ago
I think both of those are good reasons, but there's also: C. Web applications are the way most applications are used on desktop nowadays. The creator already needs to eat the cost of hosting the servers, so you might as well go for control and monetization over delving into making peer to peer work.

jll29 5y ago

Any new ideas for missing protocols, HN? More than finger, I so miss the times of USENET and the user experience of its hierarchical system of groups with threaded, text-only pull messages (I accessed it from gnus (the emacs newsreader) via my HP 9000 715 running HP-UX 9.03).

clarkmoody 5y ago
The Gemini protocol is an interesting re-imagining of Gopher: extremely simple text-only content, with client-side styling. Identification via client-side certs.
azinman2 5y ago
I’m sure you could write a Reddit client that emulates this. For better or worse, it’s the most like Usenet today.
- layer8 5y ago
  The most important difference a Usenet-like clients brings is per-message read/unread status, which is what enables long-running threads and discussions. Without most clients (most users) supporting such read/unread tracking, you won’t have long-running discussions, which changes the whole character of the medium. Per-message read/unread status in practice requires keyboard navigation (or as an inferior alternative, paging with read/unread tracking like in web forums), which doesn’t work for mobile. The lack of read/unread tracking is also why we don’t have long-running discussions on HN. The only remaining medium with per-message read/unread tracking we currently have is mailing lists.
  - spc476 5y ago
    Not to mention kill files, allowing you to filter out people/topics/threads you don't wish to read.
    - gerikson 5y ago
      Reddit Enhancement Suite is a sort of swiss army knife killfile. Sadly I don't think it is long for this world of New Reddit.

deleted 5y ago

[deleted]

clarkmoody 5y ago

The Bitcoin wallet world is using Tor to tunnel from mobile apps back to full node software operating on home servers. Not necessarily an example of your first question, but definitely in the spirit of the HTTP server on phone.

marcosdumay 5y ago

Stupid security people set up stupid firewall rules that blocked everything else (they are mostly going away nowadays, finally). And then NAT and ISP port blocking happened too. And the phone thing was that on modern processors listening to the network is a serious battery sink.

not2b 5y ago
Not stupid at all: https://en.wikipedia.org/wiki/Morris_worm https://en.wikipedia.org/wiki/Morris_worm , brought to you in part by fingerd.
- marcosdumay 5y ago
  Yeah, tunneling everything over HTTP did really solve buffer overflows.
- wumms 5y ago
  From Wikipedia [0]: "Robert Tappan Morris is an American computer scientist and entrepreneur. He is best known for creating the Morris worm in 1988, considered the first computer worm on the Internet. 1988 – Released the Morris worm (when he was a graduate student at Cornell University) 2005 – Cofounded Y Combinator" [0] https://en.wikipedia.org/wiki/Robert_Tappan_Morris https://en.wikipedia.org/wiki/Robert_Tappan_Morris
- DonHopkins 5y ago
  Yeah, 4.2 BSD fingerd was calling "gets" to read the name of who you were fingering into a small fixed size buffer on the stack. https://man7.org/linux/man-pages/man3/gets.3.html https://man7.org/linux/man-pages/man3/gets.3.html Chris Torek had hacked our version of fingerd (running on mimsy.umd.edu and its other Vax friends brillig, tove, and gyre) to implement logging, and while he was doing that, he noticed the fixed size buffer, and thoughtfully increased the size of the buffer a bit. Still a fixed size buffer using gets, but at least it was a big enough buffer to mitigate the attack, although the worm got in via sendmail anyway. And we had a nice log of all the attempted fingerd attacks! The sendmail attack simply sent the "DEBUG" command to sendmail, which, being enabled by default, let you right in to where you could escape to a shell. Immediately after the attack, "some random guy on the internet" suggested mitigating the sendmail DEBUG attack by editing your sendmail binary (Emacs hackers can do that easily of course, but vi losers had to suck eggs!), searching for the string "DEBUG", and replacing the "D" with a null character, thus disabling the "DEBUG" command. But unfortunately that cute little hack didn't actually disable the "DEBUG" command: it just renamed the "DEBUG" command to the "" command! Which stopped the Morris worm on purpose, but not me by accident: I found that out the day after the worm hit, when I routinely needed to check some bouncing email addresses on a mailing list I ran, so I went "telnet sun.com 80" and hit return a couple times like I usually do to clear out the telnet protocol negotiation characters, before sending an "EXPN" command. And the response to the "EXPN" command was a whole flurry of debugging information, since the second newline I sent activated debug mode by entering a blank line! So I sent a friendly email to postmaster@sun.com reporting the enormous security hole they had introduced by patching the other enormous security hole. You'd think that the Long Haired Dope Smoking Unix Wizards running the email system at sun.com wouldn't just apply random security patches from "some random guy on the internet" without thinking about the implications, but they did!

ReactiveJelly 5y ago

TLS was hard, the implementations kinda sucked, and it turned out that it was important. So we went through a dark age where "Just open a socket and have at it" couldn't fly over WAN, which means there wasn't much point doing it at all. QUIC will fix this. You can treat it like a bunch of TCP streams and UDP datagrams that are Just Encrypted. I'm thinking about doing a toy IRC knock-off with QUIC. Having TLS standardized in the transport layer means less work for the app, and having multiple streams and datagrams means that odd stuff like file transfers or even voice chat could be tacked on without opening new ports or new TCP streams. Matrix is cool and all, but I want something you can just throw down for a few friends and some bots with a shared password. Matrix homeservers are too much work for one-off. My old New Year's resolution was always "I'm finally gonna get into web dev". But I don't like web browsers. My new resolution will be "I'm gonna do web stuff, without web browsers."

ldehaan 5y ago
I'm building a webrtc video based dungeons and dragons app so my sister can DM for my kids and I instead of using Skype/hangouts/discord etc.. which all suck because she's in . So all that to just say I did it in Electron and it was a cinch and I'm doing mobile versions with Ionic. Both are web dev without exactly using browsers, but still using browser engines. Could be fun.
passerby1 5y ago
Interesting, as I went into webdev too some two years ago for a year and a half, it was a good experience. What're your pain points in browsers?
- ReactiveJelly 5y ago
  I tried to bring some nuance to this. 10 years ago I would have said something more like "Fuck web browsers". I've toned back on the hate, but I still think they have serious shortcomings. (Not that native doesn't - Notice I said nothing about permissions and untrusted code) tl;dr: I think web browsers have a Pareto problem. Building inside a web browser is pretty all-or-nothing. Their interfaces make the most common 90% of cases easy but the other 10% of interesting niche stuff totally impossible, or too slow to be useful. Just like how old PC games would play music by triggering the CD drive's "Just play this track" feature, browsers are fine for doing super-high-level stuff exactly the way most people want to do it. But if you want to do anything with that audio other than stream it unmodified straight to the speakers, suddenly the APIs let you down. And the whole time, you're taking on some of the biggest dependencies in history. There are two companies that make full-sized web browsers. One is a non-profit constantly struggling for funding while making awful PR gaffs and being hypocrites about privacy. The other is an openly evil advertising company. Full: I've done really basic stuff, like I learned how HTTP works, I wrote a few web apps with Rust, I made a game with TypeScript and WebGL. But it just never clicked for me. My comment is missing a little context. There's basically two different niches: 1. If I want more than 2 or 3 people to use it, it has to run in a web browser. I don't mind doing WebGL and putting it on a static site. I can always do a native port if I feel like it. All the games I've made can be modelled as "Read keyboard input and run OpenGL commands", and browsers are enough for that. 2. If I want to really have fun with something, just for myself, web browsers are too big of a dependency and the restrictions are too tight. Sure, they'll get QUIC as WebTransport soon (IIRC), but I'm always gonna be limited by the dependencies. I don't like Electron out of principle. It's just so big. Native development can be awful - Big C projects are not fun to build. But Rust is striving for "Just clone and `cargo build`". What's the `cargo build` for web stuff? I have to set up TypeScript or something else to shield me from JavaScript... If I were using Electron I'd have to learn all that... I actually like local web UIs. I think because that offers flexibility. If I want to send a video stream from a browser, sure I "just" have to use WebRTC. But how do the WebRTC servers work? I haven't found satisfying documentation. What if I want to start with a webcam stream and then compose graphics into it before encoding? I know browsers have Skia, but is that exposed to me? Or is it like so many bad "Play an audio file" APIs where it breaks down as soon as I want to play a _remote_ audio file or _stream_ an audio file or _transcode_ an audio file. So (sorry for the meandering) back to my toy IRC idea. I can do that with HTTP and long-polling and it would kinda work. But it would just be a crappy Matrix clone. What I really want is to show off "Look, I think QUIC is going to bring back custom protocols, QUIC has not to come to abolish the word of TCP but to fulfill it, and here's how it looks." And I could do that with Electron, but like the "Let me do everything for you and make the 10% of niche cases impossible" API that can only play audio or send a webcam stream without any compositing, Electron presumes I'm going to have a GUI, and I'm also going to run it on the same computer. Whereas if I make the first prototype UI with curses or a local web UI, I can forward it over SSH easily or run it when a GUI isn't available. It sounds a lot like Gemini, but I think Gemini is a little misguided. It sounds like most of its proponents think that you can control a protocol by just having very noble goals. And it sounds like they are opposed to HTTP and QUIC not because the protocols are bad or even hard to implement (In the case of HTTP. QUIC actually is hard to implement), but just because bad entities use them. I think it's dangerous to believe that powerful tools are only for bad purposes. It will leave good people de-powered.

tptacek 5y ago

Finger is a silly protocol. It doesn't exist anymore because it is worse in every possible way than HTTP (or, at least, the tiny subset of compatible HTTP that replaces it). I remember when I was earlier in my career and more specialized on implementing weirdo protocols hearing that HTTP was going to replace all the existing protocols. I was appalled; it seemed absurd, like suggesting Word .DOC was going to replace all text files. But for the most part, the people saying that were right, and we are better off for it. The thing about a lot of those purpose-built protocols, even the "important" ones like DNS and most especially infrastructure stuff like SNMP, is that they are pretty dumb, the product of their time and thus, by construction, deprived of several decades of systems learning.

pdpi 5y ago
HTTP does a lot of things right, but it’s almost completely oblivious to the contents of requests/responses. Things like DNS also have to specify what a query looks like, and the format for the response.
guerrilla 5y ago
You didn't make an argument for why it's a silly protocol. You didn't make an argument for why it is worse in every possible way than HTTP. You didn't make an argument for why we're better off having replaced everything with HTTP. You didn't make any arguments about they they are "pretty dumb." Your entire post amounts to "I like HTTP" and "old stuff bad."
- deleted 5y ago
  [deleted]
- nextlevelwizard 5y ago
  You didn't make an argument why it isn't a silly protocol. You didn't make an argument for why it is better in any way than HTTP. You didn't make an argument why we are worse off having replaced everything with HTTP. Your entire post was stupid and had no point other than trying to be a gotcha.

tristanc 5y ago

Does adding a header-only (C++) http server to projectM’s visualizer [0] count? I added a very basic http server to switch presets from any basic web browser (including a kindle paperwhite) using a static html page. [1] It’s been great fun hosting parties and projecting visuals across the room onto an opposite wall. Then passing around a very old Android phone to go through the presets. I highly encourage others to do the same with their favorite applications it’s fairly straightforward and makes it a pleasure to use. [0] https://github.com/hashFactory/projectm https://github.com/hashFactory/projectm [1] https://github.com/hashFactory/projectm/blob/compression/src/projectM-sdl/remote.html https://github.com/hashFactory/projectm/blob/compression/src...

binwiederhier 5y ago

> You could message the owner of phone directly through a URL. The request would be handled by server on phone! I know it's not like a web server on the phone or anything, and likely questionable to mention it at all (since I made it), but I made a thing that lets you send notifications to a phone (or desktop) via curl [0] via a simple PUT or POST. It's definitely not a cool protocol since it's simple HTTP, but it's in the spirit of other Unix tools since it's just one thing to do one job. [0] https://ntfy.sh https://ntfy.sh

Datagenerator 5y ago
Thanks, looks useful
dolmen 5y ago
Missing in the FAQ: what happens when multiple clients have subscribed on a topic (ex: via SSE)? In practice (2 SSE clients): all clients are notified.
- binwiederhier 5y ago
  Thanks for the feedback. I'll add it. Yes you are correct: It's the nature of pub-sub that all subscribers are notified if a messages arrives on a topic.

zepto 5y ago

People still do: https://mbays.sdf.org/htalkat/ https://mbays.sdf.org/htalkat/

rain1 5y ago

Gopher is still around! Get involved!

csmpltn 5y ago

It used to be the case that HTTP was used by web browsers (clients) and web servers to exchange mostly textual content. During those times, HTTP was used as a pure application-layer protocol, riding on-top of TCP (a transport-layer protocol). These days HTTP is used for everything. Server-to-Server API calls, binary data transfer, IPC, etc. A lot of these things get implemented on-top of HTTP though. HTTP is used much more as a transport-layer protocol now, an abstraction layer on-top of TCP. How did we end up here? It appears that there was an organic need to build an abstraction layer that's easier to work with than TCP, which is probably seen as too low level and much more difficult to work with. Browsers supporting HTTP out-of-the-box with AJAX made this a widespread practice. These abstractions come at high costs though.

corobo 5y ago

> Why we have stopped making cool protocols like this? Why aren't you doing it? Same reason

usb0 5y ago

I remember Nokia's MWS and if memory serves me it was powered by Apache and Python Server Pages (PSP). I thought it was crazy to port those things to mobile but somebody (reiner-keuchel.de IIRC) ported almost all open source tools to Windows Mobile long before Nokia.

aaaaaaaaaaab 5y ago

>Why we have stopped making cool protocols like this? It seems Internet had really cool protocols back in the day and we had so many possibilities. Now it seems we are stuck with HTTP. Because of corporate network firewalls. Make no mistake, they would gladly break HTTP if they could, but it became too important, so now everything has to piggyback on top of HTTP. Enforce the end-to-end principle and new protocols will flourish.