Hacker News Reader

Comment by joshaidan | Hacker News Reader

Tentd seems to be based on Ruby and Rack. Since it's based on Rack, I'm assuming then that it operates over HTTP. Which leads me to my current frustration...

Why does everything have to be built on top of HTTP? Sure, I know you're going to say, because it works, and works well that's why.

But think about it. The reason why we have all these centralized services in large part is because of HTTP. HTTP has made it really easy for someone to build a centralized service, or application, like Facebook or Twitter. Before the days of HTTP, if I wanted to build a service, I probably would invent a protocol like Telnet, Gopher, SMTP, IRC etc., which is often naturally decentralized, instead of programming a web application.

Perhaps if we want more decentralized services, we should focus on frameworks that make it easier to construct TCP/UDP based protocols.

Just a thought.

View on HN

Very few people will be able to use non-HTTP protocols from their company networks. A significant number of home users behind NAT won't be able to use them without configuration steps that normal users simply won't make.

To that add the fact that there's actually minimal benefit for most protocols to using something other than HTTP. Obviously there are protocols that are much better run over something other than HTTP, but most protocols, probably including Tent, aren't like that.

http://cr.yp.to/sarcasm/modest-proposal.txt

Corporate networks are followers when it comes to social software. If a protocol becomes very popular among users eventually corporations will give in and make it available. Companies used to block HTTP also.

That has absolutely not been my experience in the last 8-9 years of doing onsite engagements for corporations. You can usually count on HTTPS getting through unmolested. Usually.

I meant back in the 90s. I worked at a couple of companies that saw no reason to give their users access to the internet which was seen as a time waster. I haven't come across that attitude in a very long time, even though there's probably more time wasted now than ever.

Sorry, message board fail. I was saying that you're lucky if you can get web traffic through corporate firewalls unmolested. You can only rarely get anything else out, and virtually never get anything in.

Normal users (ie, users behind NAT) shouldn't be running their own Tent servers, period. People who run their own servers are geeks by definition and can/should host in the cloud. Where "cloud" means "that part of the Internets that actually works."

But your second point is unanswerable. I'd go a little farther and say HTTP is actually a pretty good fit for Tent.

> Normal users shouldn't be running their own Tent servers

I used to agree with you that the general public shouldn't run their own server, but that argument may no longer apply.

For example, my home PC (a mac) wakes up from sleep whenever I remotely need something off of it (took no setup on my part). The machine is always backed up, and already has all of my photos and address book. It's been just as reliable as my paid shared web host. So, why not start deploying services from our home PCs.

Think of the obvious benefit—I no longer have to upload photos. Given some additional thought I bet we could come up with other benefits to hosting from home.

I'm not quite ready to advocate for this, but maybe it's time to reconsider this assumption.

Your home PC isn't really on the Internet. It's on a crappy pseudo-network that happens to be connected to the Internet.

This doesn't mean you shouldn't be able to use it as a server - you should. However, to use it as a server, you'll need a proxy/gateway server on the real Internet (ie, in the cloud) and a pseudo-protocol by which the gateway talks to your home PC. The pseudo-protocol could even look a lot like the protocol that real servers speak to each other on the real Internet - but there's no requirement that they be the same. (I'm not sure how well inbound port 80 works if you're on Comcast, anyway.) So, when designing the real-server protocol, it's a layering violation to also be thinking about this pseudopod.

There is no such thing as a layering violation. You should be immediately suspicious of anyone who claims that there are such things.

I've got it - we'll encode Ethernet frames in JSON and tunnel them over HTTPS to an IP stack in Javascript. With a JS DHCP client, your browser will grab an IP address on the same subnet as the cloud server. And it's business up front, party in the back...

"Layering violation" is not the best term for what I meant, which is just "design mistake." Also the OSI model doesn't have much to do with reality. But if you want layering violations...

Let me see if I understand the argument you've made: the idea that there are no layering violations is silly because people can make bad designs? Should we blame poor layering discipline for all the C code out there that calls gets(3)?

Modularity is a good thing. Composability often is too. For systems deployed in the large, the end-to-end argument also guides designs to simple cores and complex clients.

But none of that means that any given layer "owns" any piece of functionality. It would indeed make a whole lot of sense to start thinking of IP as the new Ethernet, for instance. But we can't really do that, because the greybeard priesthood uses concepts like "layering violation" to shut down discussion and maintain intellectual turf.

I don't think we're arguing about anything substantive. For the record, I shave my neck every day. I also have no problem with thinking of IP as the new Ethernet.

By "layering violation" I really meant "layering" in a systems rather than a protocol sense. For example, it'd be a "layering violation" in this sense if your OS had a system call print_powerpoint_document(2).

Modularity, compositions, and reusable/flexible kernels are strong design components. "Layers" are a straitjacket. I'm automatically suspicious of designers who invoke them, because they tend to have more to do with shutting down discussions than they do with designing. That's all.

Please read definition of "inter". The Internet is a collection of crappy networks.

The gateway between your crappy network and the Internet is on the Internet. A node on your crappy network, however, is on your crappy network.

(What's unfortunate is that IPv6 seems destined to become no more than one of these "crappy networks.")

Your home PC isn't really on the Internet. It's on a crappy pseudo-network that happens to be connected to the Internet.

The hell are you talking about? I know I have a public IP address and am running several wikis, a Minecraft server and a Mumble server from my home, accesible via Internet (behind a firewall).

Next up is a SIP/XMPP server. Or maybe tent?

s/Your home/Your average home/

Including my dorm room (it was port restricted), my college apartment, my father's house, and my current home, I've always had a publicly accessible IP address.

Um, What? HTTP is a transport. And last I checked, the web is the worlds largest distributed application... connected by... HTTP! On top of that, virtually every language has excellent HTTP libraries. There is little and less to gain by using something new or unique at this layer of the application. Using HTTP jump starts the dialogue to the next level by not reinventing the wheel and being mired in endless technical protocol discussion that does not forward the functionality of the platform.

Yes, all valid points. And yes, particularly as a transport protocol it would, like other protocols lead to decentralized services. But perhaps I should clarify a bit and say that, HTML and the web browser have led the Internet into a place with lots of centralized services.

If we see HTTP as a transport protocol like UDP or TCP, then yes you're very right. But if we look at HTML and web browsers becoming denominate applications of the Internet, then I believe that's how a lot of this centralization happened.

If you look at the web as a series of servers, sure it's decentralized. But contained on those servers are a lot of centralized services, i.e. Facebook, YouTube, etc.

You should check out buddycloud.org. I'm not in any way connected to it, but I saw it mentioned on HN a couple months back. It is based on XMPP for the backend, but the documentation indicates a webclient, as well as mobile clients. Their documentation seems quite extensive and it was part of Google Summer of Code this past summer.

I'd be interested in hearing other people's take unless it involves "XMPP is too complicated."

I don't follow how HTML leads to centralized services. Explanation?

> Why does everything have to be built on top of HTTP?

Port 80 is already open.

All ports should be open between servers. (Edit: Ports should be open if you want. I'm not saying you should run without a firewall, but on a server the firewall is under your control, not your ISP's.)

A few of the DiSo protocols were based on XMPP instead of HTTP.

That's not true either. The best practices for running services on EC2, for instance, don't leave anything but port 80 open by default. That's a good thing, because if the best practices were anything else, people would routinely lose their databases to people guessing "admin/mysql" over the Internet.

> All ports should be open between servers.

No thanks.

How about an "open" port with nothing listening on it? What does "open" mean?

I think his point is that two nodes should be able to open and then connect on any port they choose, not just TCP 80. Please correct me if I'm wrong.

Are we saying that a user should not even be _allowed_ to have an application listen on any port except a known few?

Isn't the more important issue whether an application/process is actually listening on a port? I mean you can send me all the nasty bits you want but unless I'm prepared to receive them, what difference does it make? And I thought the whole premise here is that the only people on this social network are ones you know. They shouldn't be deliberately sending you nasty bits anyway.

I am a unixnoob. Please go easy on me for my ignorance.

I think it is true that if nothing is listening on the port, then the packets will be dropped by the OS. However, you may have services you are unaware of running, or malicious software which has snuck in, or a running application which would be listening on the port if it was open. Perhaps you want to run a webserver on localhost for testing, and by keeping the ports closed you block remote access. For these reasons it is generally regarded as bad practice to leave all ports on a server open to the public.

Maybe your servers, not mine.

Maybe this is another part of the problem. Limiting ourselves to port 80 limits the types of services we can create. But on the other hand, if we really wanted to run a service, then we would just open up the port.

But yes, NAT does complicate things, particularly for home users, but I guess that's a limitation of the universe.

Good luck with that and fanatical ops guys.

This. So much this.

The notion that everything has to be HTTP annoys me too.

Done. But still not ready for the "do everything in a graphical web browser" crowd. And that's what tent appears to be aiming at. People who think all connection must be made through a web browser.

You mean http://www.complang.org/dsnp/

Reply on news.ycombinator.com