5 ms·

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

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.

MatthewPhillips 14y ago
> Why does everything have to be built on top of HTTP? Port 80 is already open.
- wmf 14y ago
  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.
  - tptacek 14y ago
    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.
  - MatthewPhillips 14y ago
    Maybe your servers, not mine.
  - keypusher 14y ago
    > All ports should be open between servers. No thanks.
    - unixnoob 14y ago
      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.
      - keypusher 14y ago
        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.
- joshaidan 14y ago
  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.
  - kordless 14y ago
    Good luck with that and fanatical ops guys.
tptacek 14y ago
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 http://cr.yp.to/sarcasm/modest-proposal.txt
- cyarvin 14y ago
  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.
  - josho 14y ago
    > 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.
    - cyarvin 14y ago
      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.
siculars 14y ago
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.
- joshaidan 14y ago
  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.
  - 18pfsmt 14y ago
    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."
  - MatthewPhillips 14y ago
    I don't follow how HTML leads to centralized services. Explanation?
darkhorn 14y ago
You mean http://www.complang.org/dsnp/ http://www.complang.org/dsnp/
unixnoob 14y ago
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.
Zash 14y ago
This. So much this. The notion that everything has to be HTTP annoys me too.

MatthewPhillips 14y ago

> Why does everything have to be built on top of HTTP? Port 80 is already open.

wmf 14y ago
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.
- tptacek 14y ago
  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.
- MatthewPhillips 14y ago
  Maybe your servers, not mine.
- keypusher 14y ago
  > All ports should be open between servers. No thanks.
  - unixnoob 14y ago
    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.
    - keypusher 14y ago
      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.
joshaidan 14y ago
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.
- kordless 14y ago
  Good luck with that and fanatical ops guys.

tptacek 14y ago

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 http://cr.yp.to/sarcasm/modest-proposal.txt

cyarvin 14y ago
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.
- josho 14y ago
  > 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.
  - cyarvin 14y ago
    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.

siculars 14y ago

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.

joshaidan 14y ago
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.
- 18pfsmt 14y ago
  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."
- MatthewPhillips 14y ago
  I don't follow how HTML leads to centralized services. Explanation?

darkhorn 14y ago

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

unixnoob 14y ago

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.

Zash 14y ago

This. So much this. The notion that everything has to be HTTP annoys me too.