11–20 of 229 posts
Sounds almost too good to be true. Looking forward to being able to download some software.
The idea seems pretty good. It's just the basics: you follow people and receive their content (text, images, whatever), and people follow you and you share content with them. The most amazing thing is that, just using these simple concepts the possibilities are infinite. As they said, every social network out there can be implemented in this way. ¿Twitter? It's trivial, just make the format description and you're ready. ¿Facebook? The only thing you should specify is that the relationships are symmetric (you can follow me only if I decide to follow you too, that is, we are mutual friends).
To me, the idea seems absolutely great. The problem will be execution: what apps are created using this protocol. I have also the doubt if apps will be interoperable. Example: I build a twitter-like app named Foo and another guy builds another twitter-like app named Bar. Both use similar formats, so, can an user using Foo see the contents posted with Bar? I imagine that this will be possible as long as they share the same post format, but I'm not sure.
Anyways, good work. I would really like to see Tent to expand and grow.
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…
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.
Earlier quoted context omitted.
Diaspora* is a federated open source social network. It does not have a protocol specification or an API for app support/integration. Diaspora* is not intended to be run as one server/user, but by clustering users on pods with pod administrators, etc.
Reading the API docs, it seems that every user needs their own URI to be uniquely identified. I wonder how this will work with the average user, just IP address? What about users with shared internet?
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…
[deleted]
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: FirewallsIf a million people decide to 'camp in my tent' (?), my server is suddenly pushing out gigs of data every time I make a post.
My first thought was "Well, Diaspora with another name". But after reading and understanding it (it's not very well explained there) seems like a much more abstract thing. They want to build an abstraction layer to the social web, not a social network. The idea seems pretty good. It's just the basics: you follow people and receive their content (text, images, whatever), and people follow you and you share content wit…
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…
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 access…
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 :)
It seems like this will use up a crapton of bandwidth with its 'push' style notifications. If someone with a million Facebook followers makes a new post, one entry is made in the database and then users pull it down as they visit their own pages. If a million people decide to 'camp in my tent' (?), my server is suddenly pushing out gigs of data every time I make a post.
We also have a setting in subscriber settings that control which types of posts are pushed in their entirety to different followers vs just a notification being sent vs nothing at all. So blog entries and status updates might get pushed to all 1M, but you probably wouldn't push an HD video update to all of them without some more serious server architecture.