7 ms·

Why is it that every new protocol seems to want to piggy back on HTTP? It seems to me that maintaining state would be a useful feature for a social protocol. A

by mbreese 14y ago

Why is it that every new protocol seems to want to piggy back on HTTP? It seems to me that maintaining state would be a useful feature for a social protocol. Another issue is that this assumes that the web will be the client of choice in the future... with mobile apps being as big as they are in the social space, this seems a bit shortsighted. Don't get me wrong, I like the idea behind having a "social server", but I don't necessarily think that starting with HTTP is the way to go. I don't have any particular argument with using JSON for data transfer though... I think that is probably a good choice. Also using SSL for all connections is probably a good call too.

deleted 14y ago
[deleted]
- mbreese 14y ago
  These aren't meant to be run from personal workstations behind firewalls, they are meant to run on servers. Firewalls in this instance shouldn't be an issue. If firewalls were actually an issue, you could always run the service on port 443. I don't know how you'd tell anyone else that you're running on a non-standard port, but it would be possible. That's actually another potential problem... this is a server that is masquerading as an HTTPS server... I hope that it plays nice with non-Tent HTTP clients. It isn't nice to hijack ports like that. They are seem to be assuming a web-based client, so that traffic (which does need to worry about firewalls), should pass though a firewall without issue. Edit: parent got deleted, it was One word: Firewalls
pwf 14y ago
They describe it as a 'protocol' on top of HTTP; I don't think that assumes much about the 'client of choice'. Most apps I've worked with already use HTTP and JSON anyway.
Titanous 14y ago
HTTP accomplishes all of our design constraints via REST and long-lived streaming connections. It is a very reliable, mature protocol, and the security and performance are very well understood. Also, if we invented a new binary protocol, users wouldn't be able to host their Tent servers on easy-to-use platforms like Heroku. Developers may implement other protocols in the future, but we are targeting HTTP as an accessible starting point. We are definitely anticipating heavy mobile use, both through mobile web apps as well as native. There will eventually be iOS and Android frameworks to handle all of the communication with Tent servers.
- mbreese 14y ago
  You wouldn't have to invent a new binary protocol, a simple text protocol can work wonders (see: memcached or Redis). I'd personally look more towards SMTP for inspiration (not security wise, of course). Since you're going to mainly be passing messages back and forth, not resources. You really should also think about two separate protocols... one server-to-server, the other server-to-client. At least, that's how I've been working on it :)
  - danielsiders 14y ago
    Actually, we do support passing resources back and forth and for a lot of use cases doing so saves quite a few round trips in the long run. Our protocol has two distinct parts, one server-server, the other server-app. It's just easier to manage a single "API" than having some support server-server but not server-app--we're hoping to avoid ecosystem fragmentation into those who don't want to support apps or vice versa.
- flatline3 14y ago
  HTTP is a huge, hefty, inefficient and complex protocol whose only advantage is that HTML/JS supports it by default. Arguments that 'websockets' solve this are ridiculous in the face of the fact that we can just use 'sockets', like we always have. WebSockets are a work-around for the constraints of the browser. As a mobile/desktop/server engineer, I would love the opportunity to work with other server-side teams that aren't wedded to the web/HTTP via historical accident and thus don't force us to use HTTP.
  - TazeTSchnitzel 14y ago
    WebSockets also have the advantage that they pass through corporate firewalls and open wifi networks, as well as many proxies, as they masquerade as HTTP traffic. And a nicer frames mechanic than raw socket, something I love. (nowhere near as low-level, but for me it's essentially stateful UDP that's reliable, i.e. TCP except with datagrams)
    - 14y ago
bickfordb 14y ago
People build things on top of HTTP because HTTP is a pretty general, reasonable, easy to implement protocol; most alternative protocols tend to re-invent something like it or not become popular. Most protocols resemble or can be implemented on top of (Action, URI, Headers, Body) => (Status, Headers, Body). Most of the improvements suggested to HTTP tend to come in the form of encoding messages more efficiently at the cost of extensibility. Reasonably efficient HTTP servers exist for every platform. I'm not sure exactly what you mean by maintaining state, but if you mean long-lived connections: this already exists in HTTP with chunked-encoding and the new web socket extensions. Stateful protocols tend to be more difficult to write programs for and load balance.
gnaritas 14y ago
> Why is it that every new protocol seems to want to piggy back on HTTP? For the same reason cars all want to drive on the same roads.
mmahemoff 14y ago
I upvoted this as it's good to question the assumption and it's easy to imagine this working better without HTTP. In practice though, I feel the project is orders of magnitude more likely if it's built with HTTP and REST. A social product needs to reach critical mass and any hurdles you're putting in front of users and developers need to be seriously justified. In this case, workarounds like cookies are Good Enough.
- flatline3 14y ago
  I'd argue that -- for native client authors -- HTTP and REST are actually larger barriers than a simple non-HTTP protocol. I also don't understand the concern over "inventing" a new binary protocol. It's not like it's any more complicated or difficult than "inventing" a non-binary protocol. The framing rules just don't use ASCII/UTF-8 field delimiters. There are plenty of existing encodings to use, no more difficult than JSON.
  - TazeTSchnitzel 14y ago
    Only if you're using C/C++ and only native OS libraries (or on windows, afraid to use WinHttp for fear of lack of SP1 support)
    - flatline3 14y ago
      Marshalling back and forth between HTTP requests and in-app models via the like of NSURLConnection is far more ugly to do cleanly and efficiently than a simple state machine modeled on message passing over a socket.
      - TazeTSchnitzel 14y ago
        That's only for Objective-C, it's nicer in Go.
notatoad 14y ago
Http gets let through firewalls. Other protocols don't.
exact-ly 14y ago
My thoughts are similar. All due respect, this is a brittle approach and vary narrowly targeted. Relying on HTTP, SSL, Ruby, JSON does not inspire confidence . When I see "Ruby 100%" on the github page for something that aims to move us forward out of centralisation, it makes me shudder. You need to think beyond the web, and get lower level (Tor hidden services, being outside the centralised web, are the right idea, but Tor has a certain stigma). You do need to get below the level of partisan languages- for a number of reasons, one of which is to make it open and easy for anyone to build on, not just web developers and people who know certain languages. That's a given. Get people connected (stateful) and all that will follow. Something more like cjdns. It's the connection that's important, not the web or whatever else you chose to use the connection for. A webserver is one of many things that can be offered over a connection. I don't want to make the connection through an all-purpose application like a web browser, written by some company (Chrome in all its complex glory is trying to supplant your OS's DNS fer chrissakes, wake up- in the end, it's all about control). I want a very small and simple open source app that handles the connection to my peers and which works via the OS, not "the web". It makes the connection, keeps it alive and otherwise stays out of the way. I think these kids need to go back to the drawing board. But anyone working on stuff like this should not give up! Whatever the successor to centralised social networking is, it will largely be a matter of timing. The best solution might not prevail. Instead it might be the one that hits the news at exactly the right time and catches on for some unexplainable reason. There will be more to come. That's a promise.
- icebraining 14y ago
  What centralized web? Barring DNS - which is not mandatory for the web - there's no such thing. The web is completely decentralized. Using the web essentially means, "when making a request, use a client-server model and communicate using HTTP", nothing more, really. Tor hidden services, being outside the centralised web, are the right idea But most Tor hidden services are as much as the web as normal web services! They talk in a server-client model using HTTP - that's the web, right there. I don't want to make the connection through an all-purpose application like a web browser Using the web doesn't mean using a web browser. written by some company (Chrome in all its complex glory is trying to supplant your OS's DNS fer chrissakes, wake up- in the end, it's all about control). ...and it certainly doesn't mean using Chrome or other browser written by some big company; there's Amaya, Arora, Camino, Dillo, Dooble, ELinks, Flock, Galeon, GNU IceCat, K-Meleon, Konqueror, Links, Lynx, Midori, Firefox, SeaMonkey, Shiira, Uzbl, Luakit and more. I want a very small and simple open source app that handles the connection to my peers and which works via the OS, not "the web". It makes the connection, keeps it alive and otherwise stays out of the way. Which is completely feasible using HTTP - the web - as a core protocol.

by mbreese 14y ago

deleted 14y ago

[deleted]

mbreese 14y ago
These aren't meant to be run from personal workstations behind firewalls, they are meant to run on servers. Firewalls in this instance shouldn't be an issue. If firewalls were actually an issue, you could always run the service on port 443. I don't know how you'd tell anyone else that you're running on a non-standard port, but it would be possible. That's actually another potential problem... this is a server that is masquerading as an HTTPS server... I hope that it plays nice with non-Tent HTTP clients. It isn't nice to hijack ports like that. They are seem to be assuming a web-based client, so that traffic (which does need to worry about firewalls), should pass though a firewall without issue. Edit: parent got deleted, it was One word: Firewalls

pwf 14y ago

They describe it as a 'protocol' on top of HTTP; I don't think that assumes much about the 'client of choice'. Most apps I've worked with already use HTTP and JSON anyway.

Titanous 14y ago

HTTP accomplishes all of our design constraints via REST and long-lived streaming connections. It is a very reliable, mature protocol, and the security and performance are very well understood. Also, if we invented a new binary protocol, users wouldn't be able to host their Tent servers on easy-to-use platforms like Heroku. Developers may implement other protocols in the future, but we are targeting HTTP as an accessible starting point. We are definitely anticipating heavy mobile use, both through mobile web apps as well as native. There will eventually be iOS and Android frameworks to handle all of the communication with Tent servers.

mbreese 14y ago
You wouldn't have to invent a new binary protocol, a simple text protocol can work wonders (see: memcached or Redis). I'd personally look more towards SMTP for inspiration (not security wise, of course). Since you're going to mainly be passing messages back and forth, not resources. You really should also think about two separate protocols... one server-to-server, the other server-to-client. At least, that's how I've been working on it :)
- danielsiders 14y ago
  Actually, we do support passing resources back and forth and for a lot of use cases doing so saves quite a few round trips in the long run. Our protocol has two distinct parts, one server-server, the other server-app. It's just easier to manage a single "API" than having some support server-server but not server-app--we're hoping to avoid ecosystem fragmentation into those who don't want to support apps or vice versa.
flatline3 14y ago
HTTP is a huge, hefty, inefficient and complex protocol whose only advantage is that HTML/JS supports it by default. Arguments that 'websockets' solve this are ridiculous in the face of the fact that we can just use 'sockets', like we always have. WebSockets are a work-around for the constraints of the browser. As a mobile/desktop/server engineer, I would love the opportunity to work with other server-side teams that aren't wedded to the web/HTTP via historical accident and thus don't force us to use HTTP.
- TazeTSchnitzel 14y ago
  WebSockets also have the advantage that they pass through corporate firewalls and open wifi networks, as well as many proxies, as they masquerade as HTTP traffic. And a nicer frames mechanic than raw socket, something I love. (nowhere near as low-level, but for me it's essentially stateful UDP that's reliable, i.e. TCP except with datagrams)
  - 14y ago

bickfordb 14y ago

People build things on top of HTTP because HTTP is a pretty general, reasonable, easy to implement protocol; most alternative protocols tend to re-invent something like it or not become popular. Most protocols resemble or can be implemented on top of (Action, URI, Headers, Body) => (Status, Headers, Body). Most of the improvements suggested to HTTP tend to come in the form of encoding messages more efficiently at the cost of extensibility. Reasonably efficient HTTP servers exist for every platform. I'm not sure exactly what you mean by maintaining state, but if you mean long-lived connections: this already exists in HTTP with chunked-encoding and the new web socket extensions. Stateful protocols tend to be more difficult to write programs for and load balance.

gnaritas 14y ago

> Why is it that every new protocol seems to want to piggy back on HTTP? For the same reason cars all want to drive on the same roads.

mmahemoff 14y ago

I upvoted this as it's good to question the assumption and it's easy to imagine this working better without HTTP. In practice though, I feel the project is orders of magnitude more likely if it's built with HTTP and REST. A social product needs to reach critical mass and any hurdles you're putting in front of users and developers need to be seriously justified. In this case, workarounds like cookies are Good Enough.

flatline3 14y ago
I'd argue that -- for native client authors -- HTTP and REST are actually larger barriers than a simple non-HTTP protocol. I also don't understand the concern over "inventing" a new binary protocol. It's not like it's any more complicated or difficult than "inventing" a non-binary protocol. The framing rules just don't use ASCII/UTF-8 field delimiters. There are plenty of existing encodings to use, no more difficult than JSON.
- TazeTSchnitzel 14y ago
  Only if you're using C/C++ and only native OS libraries (or on windows, afraid to use WinHttp for fear of lack of SP1 support)
  - flatline3 14y ago
    Marshalling back and forth between HTTP requests and in-app models via the like of NSURLConnection is far more ugly to do cleanly and efficiently than a simple state machine modeled on message passing over a socket.
    - TazeTSchnitzel 14y ago
      That's only for Objective-C, it's nicer in Go.

notatoad 14y ago

Http gets let through firewalls. Other protocols don't.

exact-ly 14y ago

My thoughts are similar. All due respect, this is a brittle approach and vary narrowly targeted. Relying on HTTP, SSL, Ruby, JSON does not inspire confidence . When I see "Ruby 100%" on the github page for something that aims to move us forward out of centralisation, it makes me shudder. You need to think beyond the web, and get lower level (Tor hidden services, being outside the centralised web, are the right idea, but Tor has a certain stigma). You do need to get below the level of partisan languages- for a number of reasons, one of which is to make it open and easy for anyone to build on, not just web developers and people who know certain languages. That's a given. Get people connected (stateful) and all that will follow. Something more like cjdns. It's the connection that's important, not the web or whatever else you chose to use the connection for. A webserver is one of many things that can be offered over a connection. I don't want to make the connection through an all-purpose application like a web browser, written by some company (Chrome in all its complex glory is trying to supplant your OS's DNS fer chrissakes, wake up- in the end, it's all about control). I want a very small and simple open source app that handles the connection to my peers and which works via the OS, not "the web". It makes the connection, keeps it alive and otherwise stays out of the way. I think these kids need to go back to the drawing board. But anyone working on stuff like this should not give up! Whatever the successor to centralised social networking is, it will largely be a matter of timing. The best solution might not prevail. Instead it might be the one that hits the news at exactly the right time and catches on for some unexplainable reason. There will be more to come. That's a promise.

icebraining 14y ago
What centralized web? Barring DNS - which is not mandatory for the web - there's no such thing. The web is completely decentralized. Using the web essentially means, "when making a request, use a client-server model and communicate using HTTP", nothing more, really. Tor hidden services, being outside the centralised web, are the right idea But most Tor hidden services are as much as the web as normal web services! They talk in a server-client model using HTTP - that's the web, right there. I don't want to make the connection through an all-purpose application like a web browser Using the web doesn't mean using a web browser. written by some company (Chrome in all its complex glory is trying to supplant your OS's DNS fer chrissakes, wake up- in the end, it's all about control). ...and it certainly doesn't mean using Chrome or other browser written by some big company; there's Amaya, Arora, Camino, Dillo, Dooble, ELinks, Flock, Galeon, GNU IceCat, K-Meleon, Konqueror, Links, Lynx, Midori, Firefox, SeaMonkey, Shiira, Uzbl, Luakit and more. I want a very small and simple open source app that handles the connection to my peers and which works via the OS, not "the web". It makes the connection, keeps it alive and otherwise stays out of the way. Which is completely feasible using HTTP - the web - as a core protocol.