Comments (33)
from tent.io.
We originally began by attempting to use and revise the OStatus protocol. These are our main complaints:
- no support for private messaging, account privacy, post privacy, etc
- inability to move relationships when moving servers/identifiers
- no standard API for application interaction
We are working on a comparison page that will address OStatus in more detail.
from tent.io.
Technically Tent.io didn't have support for those three things (and more) either when it was created. Is it difficult to build on top of ostatus's work?
from tent.io.
It's my understanding that since public/private keys are already generated when you use Salmon, private messages in OStatus would be a possibility.
Point 2 seems legit, but I'm not sure how often you'd actually want to do that.
Three, I'm not sure what you mean. Could you clarify, please?
from tent.io.
@krainboltgreene Tent does support all of these features from day 1 (today). We strongly considered Atom, PubSubHubbub, and OStatus before starting Tent. The OStatus spec clearly declares Client APIs, Private messages, syntax, and graphs as out of scope. Because of its reliance on Atom feeds, the protocol would have to be completely reimplemented to support the features mentioned, as @steveklabnik said, it's overcomplicated already. If all you want to do is send public messages out to the world, OStatus works fine and has community support.
@steveklabnik In Tent all the server does is provide an API that other apps and servers consume. To implement an rstat.us-like microblogging service, you would write a Tent application that interacts with Tent servers. OStatus doesn't have this distinction and only specifies a limited server communication format.
from tent.io.
Leaving everything else in OStatus aside, I think the JSON Activity Streams spec might be helpful for content types, rather than reinventing the wheel and maintaining a list of common types on the tent.io site.
You can easily imagine each post being an encapsulated JSON ActivityStreams item. One of the major advantages would be the inherited content types in ActivityStreams: you could have a very specific content type (loaf of bread recipe) that falls back to a generic type (text note) for client apps that don't support it. This would also open the possibility for content compatibility between apps that don't necessarily all support the tent.io protocol.
Also definitely worth reaching out to the OStatus community regarding your complaints. These are all things they've been thinking about, and they might have some useful ideas at the very least.
from tent.io.
@titanous thanks for clarifying.
I think it's really unfortunate that people are building platforms on top of platforms on top of platforms, but I guess we'll all figure it out someday.
I'll be reading the spec much more closer later, thanks for putting up with me :)
from tent.io.
OStatus cannot have private messaging as the protocol does not manage identity. It also is not concerned with application interaction as it is a communication protocol. Those standards also exist, though, and are used (ALPS, vcard, etc). The creation of another standard only serves to pollute the space, which runs oddly counter to the goals of tent.io.
Identity should be detached from service, as it is with something like ostatus. OStatus would have too much privilege if it considered identity this way. The principle of least privilege is used, instead, to encapsulate identity to another protocol (ideally running on another separate server.) A protocol for managing identity is Webfinger. OStatus assumes nothing about keys, identity, etc. That's a good thing.
So, we can add things on top of it that can do these things that use existing things phew:
Webfinger and PuSH authentication can be used to implement private feeds rather easily: http://blog.romeda.org/2011/03/private-webhooks-private-feeds.html
Webfinger and RSA implement private messages. Just sign a salmon notification with your private key and the recipient's public key. You are right, there is no activity for 'private message.' That's not part of ostatus, that'd be part of activity streams if you wanted it to be an activity like other social things.
What do you do? Hmm. Maybe it is out-of-scope for Activity Streams, which seems to be really about public events, which may be why it doesn't exist, so you create a content type for a salmon notification (which is just a signed wrapper around json or xml or something) and you do your thing and everybody that doesn't understand ignores it and every one that does uses it. You get that specification reviewed and published.
For point 2, I'm not sure what you mean either. Moving your ostatus server location is trivial if your identity is detached, since that identity contains the relationships, urls, etc. Migration of data requires a notification to the hub and end nodes. OStatus isn't concerned with export of this information as it is a communication protocol and doesn't require you to represent or use the data in any particular way. At any rate, you can pull out the information from a server as a client using http and refollow or do whatever to set-up those relationships again.
The hard part is migrating your identity. Which is exactly why it is meant to be separate. It's the internet equivalent to changing your name. And that's not trivial.
Basically, I don't think it is enough to really warrant the publishing of competing protocols. I am very weary of any group trying to organize and define all of the protocols. I'm very concerned with the monolithic nature, as in these types of designs, if there is a flaw... it stays forever. It is much harder to be flexible.
I do sympathize with your complaints about ostatus. It's a slow moving standard. But it is correct to build a standard such as ostatus that simply works on a subset of communication as a booster to the http protocol flexibility. And then build standards around it, and use them together.
I'll end by saying HTTP is a federated protocol, and it doesn't seem out of scope to add anything on top of it. Yet, we need more implementations, not more interfaces. :)
from tent.io.
this is a pretty high level comment but I think a great implementation that produces a simple set of federated protocols is a lot more practical than a bikeshedded protocol that is hard to implement. it all depends on the team building the implementation and their willingness to be good "open web citizens"
from tent.io.
After reading the spec more thoroughly, I'm not sure how 'inability to move relationships when moving servers/identifiers' is solved here at all. Is this in some draft of the spec that's not public?
from tent.io.
Just one point here as I think I indirectly addressed a bunch of this stuff in issue #6.
The ability to move relationships isn't something that's easily solved. I'm honestly not sure that data/relationship lock-in is or ever was a problem. To that point: Flickr -> [Facebook] -> Instagram is a migration that loads of people have done relatively painlessly.
Relationships: My current network on Flickr in no way represents my current network, because I built it seven years ago. I wish I could just press "reset" and start again (without 'unfollowing' people). Moving to a new network would be the easiest way to do that.
Data: Data migration is hard, but federation protocols aren't going to make that easier. Data is rich and complex, and federation will help smooth some of that over, but it will be lossy. If I'm going to move data from one network to another, it's more important that it's not lossy (or that I have some way of saving the bits that will be lost). The easiest way to get there is to just have tools that backup/migrate data. Somedaymaybe. ;-)
from tent.io.
Tent API is much better than OStatus. Let's compare:
- First and foremost, tent follows the fundamental axiom of the web in giving users an HTTP URI, OStatus does not. This means that tent is a highly web oriented protocol, OStatus is more webmail oriented.
- Tent Uses JSON, OStatus uses bespoke JRD and XRD with unclear IPR.
- Tent uses OAuth and HMAC, OAuth uses OAuth and Salmon. OAuth is pretty good, but considered a fail by many of its authors, salmon seems to be implemented differently by everyone.
- Tent uses a on open JSON schema, OStatus uses Activity Streams which is under heavy control by the lawyers.
- It seems that tent can simply use HTTP GET for discovery, OStatus uses the proposed draft webfinger, which is dependent on a new URI protocol, XML, XRD and .well-known patterns. After 3 years, webfinger has multiple authors with differing, sometimes opposing, views, It's unclear whether webfinger will make it through the IETF as a best practice in its current form.
To summarize, tent is a much cleaner web oriented protocol, leveraging the decentralized nature of the web.
One thing that is critical is to not confuse a document and an entity (tempting tho it is). in HTTP you are returned a document, which can have 0 or more data items WITHIN it, delimited by the # character. If tent can grok this element of web standards, it can potentially be a kind of glue to knit all the social nets together.
from tent.io.
Much of this boils down to preferences, (of which mine are 'implemented, supported protocols are better than theoretical protocols') but...
Activity Streams which is under heavy control by the lawyers.
Citation, please? I've never heard of this, but I'd like to know about it.
from tent.io.
@melvincarvalho @steveklabnik I'd be very curious to understand the context of that statement as well. It's true that a number of the larger contributors to ActivityStreams have taken forever to sign the OWFa, and our (Google's) lawyers requested a very minor change to the spec abstract, but that was only to clarify the scope of the spec. I've not heard of anyone's lawyers requesting substantive changes to any part of the spec.
from tent.io.
@willnorris Thanks for the clarification. The impression that I got, from following the lists for multiple years, was that there was a heavy involvement from lawyers, relative to other specs that I follow.
I'd prefer not to sightly wander off topic, as my comparison was holistic, rather than addressing one particular point.
What I wanted to get across is the Tent protocol has better potential aligned to the Web, than OStatus.
We're not all the way there yet, and there's some major pitfalls along the way, but Tent has the potential to be to OStatus, what Git was to SVN. When Linus made git, he started with identifiers, then thought about protocols, that's the key, imno. To a degree it does come down to preference, both SVN and git work, but there are subtle architectural differences.
Perhaps Tent is 80% the way to being a first class protocol, but that final 20% is often illusive. Perhaps a short trip down the road to MIT, to chat with Tim, could help. Certainly, for the reasons above, I'm really happy to see this alternative, and the conversation moving forward!
from tent.io.
I for one welcome our new JSON overlords
On Thu, Aug 23, 2012 at 10:38 AM, melvincarvalho
[email protected]:
@willnorris https://github.com/willnorris Thanks for the clarification.
The impression that I got, from following the lists for multiple years, was
that there was a heavy involvement from lawyers, relative to other specs
that I follow.I'd prefer not to sightly wander off topic, as my comparison was holistic,
rather than addressing one particular point.What I wanted to get across is the Tent protocol has better potential
aligned to the Web, than OStatus.We're not all the way there yet, and there's some major pitfalls along the
way, but Tent has the potential to be to OStatus, what Git was to SVN. When
Linus made git, he started with identifiers, then thought about protocols,
that's the key, imno. To a degree it does come down to preference, both SVN
and git work, but there are subtle architectural differences.Perhaps Tent is 80% the way to being a first class protocol, but that
final 20% is often illusive. Perhaps a short trip down the road to MIT, to
chat with Tim, could help. Certainly, for the reasons above, I'm really
happy to see this alternative, and the conversation moving forward!—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-7977595.
from tent.io.
I don't get this either..
no support for private messaging, account privacy, post privacy, etc
No one said OStatus is 'done'. Work is ongoing (not as fast as we'd hope but that's life) on privacy. See PuSH 0.4 vor authenticated feeds. Salmon can be used already today for private messages. Etc. I'm sure everyone involved in these specs would love more help and especially people who write code instead of waving hands.
inability to move relationships when moving servers/identifiers
Again, not being there today does not mean it can't be done. However there are many technical hurdles in that one. In Jabber/XMPP for example it was explicitly decided not to support such a feature for performance and security reasons (dig the mailing lists or ask Peter). Instead they've opt for a 'I've moved somewhere else' kind of mode.
no standard API for application interaction
If you mean third party app interacting with a node on your behalf, look over to OpenSocial which had wide support back in the days (MySpace, Bebo, etc.).
Yes, OStatus is not perfect, and things like Salmon interoperability is a pain that needs to be addressed. But I think that you'll have more chances to succeed by building on top of existing specs (would it be OStatus, or XMPP by the way).
On the other hand, by designing your own protocol, you'll have a lot of fun and will learn a lot of interesting things around data formats, distributed architectures, crypto, etc... Thus... do whatever you want and have fun :-) Welcome to the party.
from tent.io.
Working with existing standards is way less fun than just building your own. NIH is hard to fight. :/
from tent.io.
Working with existing standards is way less fun than just building your own.
Except when the existing standards are supported by comprehensive, robust, well-documented libraries that have a low enough barrier to entry that you can get them up and running in an afternoon, and an easy-to-use hosted service to test against. IMO. Then it's easier to use those libraries than to build something new - after all, what people really want to do is build the actual app.
from tent.io.
It's not NIH if the standard sucked. What we are arguing about is our differing opinion of the suckiness of different standards which ultimately boils down to personal taste.
If I were building tent right now then I would ignore sucky standards and use non sucky standards but first and foremost focus on making a compelling product.
from tent.io.
It's NIH if your reason that the standard sucked is "personal taste." It's not if you can objectively demonstrate that it doesn't solve your problem, or that it's worth losing compatibility with tons of existing code that already implements the standard.
from tent.io.
I can't get past the double negative.. "not not invented here" - so Max, sorry but I read "It's invented here if the standard sucked", and Steve ... "It's invented here if you can objectively demonstrate that it doesn't solve your problem."
from tent.io.
https://twitter.com/polotek/status/135449834567106560
"I wonder how many nerd arguments ultimately boil down to what level of abstraction you're personally comfortable with"
If you mapped all the decentralized web standards onto an axis going from less abstract to more abstract you would get things like "use JSON and HTTP for everything" on one end and things like "what is so hard about downloading and using Googles Java server that implements this XML standard" on the other. These are subjective decisions that add or remove amounts of time and energy required to complete something. I am personally quite glad that the Tent team has been so good at listening :)
@webr3 http://en.wikipedia.org/wiki/Not_invented_here
from tent.io.
I fully support the OStatus vision of a federated social web. I do understand there is an advantage to try and get as many people as possible to align to one system. But having followed the list, implementations and libraries for many years, I think it would be fair to say that OStatus has not quite met expectations.
Firstly, it's not a standard, in the sense that it's recognized by any standards body (e.g. W3C, IETF, OASIS), it's still in a draft stage, as are many of the various components. It may be some time before it becomes a standard, or may indeed, not make it to that far.
Tent on the other hand is using well known practices such as REST, HTTP and JSON which have been approved standards for 1-2 decades. It's putting building blocks together of these mature components in I think logical and sensible ways.
You could argue that it's NIH, and that OStatus has adoption, but I dont think even that it the case. Facebook open graph, and linked data are more widely deployed on the web than OStatus, which is an interesting tech in principle, but yet to reach any kind of critical mass, imho.
It does come down to personal preference to an extent, but I think it's unfair to criticize a young technology trying to do something innovative, just because it's not doing things the way you want. Good luck to tent and the team, v impressed so far!
from tent.io.
I would absolutely support an RFC for OStatus, but it has multiple implementations that are deployed widely, which is one of the first steps towards doing such a thing.
JSON has not been a standard for decades.
Tent is NOT RESTful.
OStatus has adoption in the way that matters: amongst the open standards and data crowd. I have big issues with OStatus, and do not think it's perfect, but you can see how "We want to be open and standard, yet we'll ignore all previous work" makes those of us who have been in this space get a little nervous.
unfair to criticize a young technology trying to do something innovative,
It's not unfair. And I've made very specific, technical criticisms. Tent is not doing anything particularly new, but reimplementing things that existing protocols do already in ways that are significantly less scaleable.
Protocol design is hard, and it's different than just building a random app and hoping that people show up and use it.
from tent.io.
@steveklabnik I think you may have perhaps misunderstood what tent is (and also maybe some of the other technologies)
"API Overview The API is RESTful, using JSON over HTTPS" <-- the first line of http://tent.io/docs
"JSON has been a well defined subset of JavaScript (specifically, Standard ECMA-262 3rd Edition—December 1999[4])" <-- http://en.wikipedia.org/wiki/JSON
I think you are being unfair to imply tent "random app", it's at least as well thought through as your preferred technology, if not better. It's fine if you want to differ, but please dont belittle a new project trying to innovate.
from tent.io.
Yes, but Tent does not follow REST, specifically the hypermedia constraint, which is an integral part of REST. They can say REST all they want, but it's not true.
JSON may have been standardized by the ECMA, but JSON itself was RFC 4627, from 2006. A long damn time in Internet Years, but not decades.
it's at least as well thought through as your preferred technology
This is where we fundamentally disagree. I am not trying to belittle the Tent devs in any way, and I'm sure they've put a lot of effort in. But they really should have consulted with some protocol designers before designing a protocol.
from tent.io.
Perhaps they mean RESTy instead of RESTful:
Why are there RESTful and non-RESTful APIs mixed up here? Have the developers been too lazy to go REST all the way? Remember, REST is an architectural style that lends itself to certain architectures (such as the CouchDB document API). But it is not a one-size-fits-all. Triggering an event like replication does not make a whole lot of sense in the REST world. It is more like a traditional remote procedure call. And there is nothing wrong with this.
We very much believe in the “use the right tool for the job” philosophy, and REST does not fit every job. For support, we refer to Leonard Richardson and Sam Ruby who wrote RESTful Web Services (O’Reilly), as they share our view.
(from CouchDB and REST on this page http://guide.couchdb.org/draft/design.html)
from tent.io.
Right. It's 'RESTish'. And that's totally fine. But when you're planning on building a protocol that's gonna scale up to (hopefully!) zillions and zillions of users, it's nice to have confidence that those building it are familiar with what exists, so they don't make mistakes like "send one POST request per follower when I update a status."
from tent.io.
There is a fine line between that and premature optimization though ("what is so hard about downloading and using Googles Java server that implements this XML standard"). Maybe if Tent presented themselves as "a startup interested in adopting and contributing to practical decentralized web standards" instead of "a new decentralized web standard" then it would be more understandable?
from tent.io.
The RESTful JSON protocol issue is a higher level issue outside the scope of tent.io.
For modern protocols to be compliant with common tool chains, they need to use the application/json media type. To be REST compliant they need to have a standardized way to say they use a "+json" mediatype, or a standardized way to use profiles. Both of which are rather raw topics at the minute.
Tent.io is doing a good job, working in an area which isn't very mature - REST and the current layers of the web aren't perfectly matched to the use cases being handled, and only after multiple people doing what tent.io are doing, can the intersection be standardized and used across multiple projects. So far, I personally thinks it's one of the most well thought out projects in active development - and I say that having a fairly good awareness of many social / federated / decentralized / rww projects; and most web arch level issues.
Standardization tends to happen on the back of innovative, active, and long term projects - particularly those which want to be / create a standard, or see a need for a certain standard.
It may be wise to foster the standardization side as a W3C community group, and interact with other related CGs, in order to really progress that side of things, and tweak out any bugs.
from tent.io.
@titanous I wouldn't do that - tent.io is as RESTful as any other JSON based protocol, and virtually every protocol I've ever seen that claims to be RESTful - even Atom isn't entirely RESTful, nor is HTTP itself, as you'll see if you read the full REST dissertation from Roy T. Fielding.
Saying you are RESTful, and being pretty much as RESTful as you reasonably can, is a good thing - remember it's an architectural style, and little more than a goal or set of good practises - not a spec which you are either implement correctly or don't.
Or, succinctly, saying something is "RESTful" is an aspirational claim, rather than a badge of conformance.
from tent.io.
wow! maybe http://www.w3.org/community/fedsocweb/ should just move to github? ;D
from tent.io.
Related Issues (20)
- Idea: allow profiles to be requested on the new_post endpoint
- How to handle attachments with identical digests on a single post
- What Content-Type to return on the attachment endpoint
- Allow the attachment endpoint to redirect to a CDN location
- Why is the attachment endpoint needed?
- Relationship post type fragment
- Posts feed pagination issue
- Use of Cache-Control can be difficult in browsers HOT 2
- Allow a "types" parameter on the mentions endpoint
- Proposal: rename app.id to app.post
- Proposal: omit urls for not supported endpoints in meta post
- Provide a Status Update HOT 3
- Notification Status
- Will tor connectivity be enforced? HOT 3
- Definition of profile sturcture HOT 2
- Finish documentation HOT 2
- Meta posts' profile.website having a duplicate option or as an array. HOT 1
- Transaction post type HOT 1
- Community Issues: How to address the barrier to entry with prospective users? HOT 10
- tent is dead! What's the reason? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tent.io.