The website for Tent — the protocol for evented data storage and decentralized communication
Home Page: https://tent.io
License: Other
This repository hosts the Tent blog and documentation. Take a look at the other repositories for Tent server and client implementations.
Compile:
bundle exec middleman build
Preview:
bundle exec middleman server
A post must require an id right? On http://tent.io/docs/post-types its says an id is optional. But the post type "Repost" requires an id.
http://www.dataprotocols.org/en/latest/syncing.html#sleep
its essentially a generic version of couchdbs multi-master streaming replication protocol without all the complicated MVCC stuff.
This may be a stretch, but since you want to be RESTful, of course, you know hypermedia is important, and a key part of REST. Many responses return a 204 at the moment, which limits hypermedia possibilities.
Related: #11
I understand some of the differences between Tent and OStatus. However, the distributed nature of Tent seems very similar to XMPP Federation and Presence PubSub. Feel free to reply and close this issue quickly, since this isn't a typical bug report. ;)
http://sioc-project.org/ defines an ontology (http://rdfs.org/sioc/spec/) for users, posts, sites, etc. Being built on RDF, problems like identification of resources are well understood (URIs are identifiers); as well as extensibility.
It should be noted, that while many of the examples in the ontology documentation will be provided in RDF/XML, there are JSON serializations (http://json-ld.org/) possible.
By aligning terms, you
I'd encourage you to consider evaluating the data model carefully, and cherry picking terms at the very least
Sometimes you use a 200, and sometimes a 204, and it's not clear to me why.
And a 201 sometimes, too.
Under 'App Registration Modification' you want to use PATCH /apps/:id, but you send application/json, which is not a diff type.
This issue would be addressed if issue 32 was fixed as using the canonical URIs for the CC licenses inherently means that there is no ambiguity about which CC license is being referenced.
Currently the example the is used repeatedly just implies "Creative Commons" while there are 6 main licenses (not counting CC0 which is a copyright waiver (eg public domain)).
You say, "Diaspora* and OStatus were the first steps in moving away from Centralized Social Service Providers, but stopped short of actual decentralization."
OStatus is decentralized; there are just some things you can't do over the network.
I'd compare email; it's a very decentralized service but there are lots of things that don't flow across the network (deletion of email, for example).
If you implement 11, an easy way of making a nice type is to use the profile pattern. Since you're using JSON rather than HTML as your base format, the spec is only an Internet-Draft at the moment. Real world implementations would help!
It looks like GETing /posts is going to give back a potentially large list of posts (probably true of all resources, but especially posts). It seems like one way to filter it would be by creating a new follower with different type filters (though I'm not sure if this is the intent).
Is there any plan for query parameters on the /posts resource to further filter the list: e.g. /posts?since={timestamp} or /posts?q={searchtext}.
I haven't had a chance to check out tentd yet, so apologies if there is something like this already.
Right now you say things like 'clients should return later' but without adopting RFC 2119, I can only guess what you mean. Consider adopting their definitions of SHOULD/MAY/MUST etc, and linking to the RFC so we can be sure. :)
Mandatory DNSSEC could be used to authenticate a Tent endpoint.
Especially when people start to self-host their Tent instances, it's important to know that the server you're talking to is actually the server of your contact.
Technical implications:
a) Pod-hosted: Everything related ot the zone signing could be handled by the 'Pod' server, which probably has a DNS server running anyway. The DNS server would publish DS records for all the users on the pod or sign the user-subzones itself.
b) Self-hosted: The self-hosted server needs a DNS record somewhere (for the A record that is also probably updated dynamically for changing IPs). With DNSSEC, the self-hosted server could host its own DNS (the published A record would instaed be a NS record pointing to another A record) and publish the signatures.
As of now there is no backchannel identify verification of a POST /followers. Somebody could make me follow every known Tent identity (probably multiple times with some URL twiddling) and DDoS my server.
This is because the Discover -> Create -> Notify path requires no auth at all but still allows me to create the Follower and the NotificationSubscription. A scheme like the one used in PubSubHubbub to verify the call could be used to address this.
Your current model means that if I have 5000 'followers', I will need to notify everyone else, no? This will be prohibitively expensive for many people.
Sounds like you have a lot of overlap here: http://tools.ietf.org/html/draft-nottingham-json-home-01
While this is also an Internet-Draft, real-world implementations help move the process along!
Mandatory TLS is in SPDY too, and there are decent criticisms of this that you can find on the ietf-http-wg mailing list. I would suggest 'HTTP without being HTTPS all the time', 'Mandatory encryption', and 'Privacy and its costs' threads.
Linked from the first thread is http://www.imperialviolet.org/2012/07/19/hope9talk.html as well.
Please see this article for premise (and shortcomings of MIME): http://arstechnica.com/apple/2005/04/macosx-10-4/11/
I much prefer UTI in your use case as it allows developers to setup in their own namespace where needed. Also, it has none of the limitations MIME presents. I don't see why technically either could not be used and accepted for stream content type specification. Existing MIME types map in a trivially easy way into UTI - but the reverse is not as true. What would make this work best is some sort of best practices and other guidelines as to the declaration of new content types - if visions of content-type chaos dance in your head upon reading this suggestion.
Please seriously consider this - life is too short to keep bumping up against the limits MIME imposes.
Cheers.
While the choice for MAC Access Authentication is a promising one, it's not a good idea to have details of the authorization inside the HTTP body. From http://tent.io/docs/server-protocol:
GET /followers/:id
GET /followers/775ecf8
Accept: application/json
Authorization: MAC id="775ecf8",
ts="1336363200",
nonce="dj83hs9s",
mac="bhCQXTVyfj5cmA9uKkPFx1zeOXM="
{
"id": "775ecf8", // What does this ID do here?
"entity": "danielsiders.com",
// ...
"mac_algorithm": "hmac-sha-256" // What does the MAC algorithm do here?
}As you can see, the id information is already present in the HTTP headers, and it belongs there.
This is not part of your request as such, but part of the authorization of your request.
If you would support another authorization method in the future, this field would be meaningless,
yet the body shouldn't depend on your authorization method.
The same goes for the mac_algorithm information, only this time there is no other place to find it.
However, the MAC Authentication draft says the usage of this paramater is only in the authorization and token response.
Examples should be real URIs, not just domains. (from #2)
Something that popped right into my mind the other day:
Facebook and Twitter are located at a single webadress. Because of this simple fact, they have been able to make a like-button for external use that checks for a login at facebook.com/twitter.com.
Once you start spreading a social network over multiple servers, this is no longer possible, unless you allow the user to set a (default) webapp for the like-button (a path to the site you are logged into). There has been some discussion on this issue over at Diaspora.
My question to the Tent developers is: have you had any thought about a unified like-button for external use that works with all tent apps? I feel that this is something that should be addressed in the protocol instead of letting each app create their own like-button.
The post types sound an awful lot like microformats, and I'm sure many of these exist. Working with that community will be useful.
It appears that you have to approve all of your followers? Is this true? I might have read this wrong. It seems vague at least.
One of the greatest things Twitter did was make following/followers asymmetric.
In the examples I repeatedly see this:
"licences": [
{
"url": "https://tent.io/types/licenses/creative-commons",
"version": "3.0.0"
}
Please consider using the canonical, stable, and semantically rich URIs provided by Creative Commons.
Every license (BY, BY-SA, BY-NC, BY-NC-SA, BY-NC-ND) along with every license version (1.0, 2.0, 2.5, 3.0, and forthcoming 4.0) along with every ported version (eg: us, uk, co, etc) has a stable, canonical, semantically rich URI.
By semantically rich URIs I mean Creative Commons followed best practices when crafting the content that is returned by those URIs to include important metadata (ccREL, DublibCore, etc).
Please don't reinvent the wheel here.
The common use case has server URIs that don't have a path component. It could be used to identify users on a service without requiring the use of subdomains.
At the moment, if a path component is specified, it is ignored per the Faraday implementation:
Faraday.new('http://localhost').get('/posts')
# => calls http://localhost/posts
Faraday.new('http://localhost/username').get('/posts')
# => calls http://localhost/posts as well
Removing the leading slash, however, makes Faraday honor the path prefix:
Faraday.new('http://localhost/username').get('posts')
# => calls http://localhost/username/posts
If it's clear that paths can't be used to create namespace on a tent server, that should be added to the spec, or the implementation should be adjusted to allow this behaviour - after all, namespacing is a great feature you get for free by using URIs. If you'd like, I can open a pull req for either.
This is of a much lesser importance than the other issues I've filed, but I figured while I was bringing other things to your attention, I should bring this one too.
This API flow is very, very, very RPC related. RPC is the antithesis of REST in many ways. This protocol happens to be even more RPC than most 'REST' APIs, which is the only reason I even bring it up.
You only mention REST once at the beginning of your docs, but not mentioning it at all would stop certain people from whining about how you're not RESTful. Better to just not give them any ammo in the first place. ;)
For more: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Embracing this and building an explicitly RPC API might also make more sense, as well.
There are times when a user may want to post information that is time sensitive. For example: if there were a post type for music or events, I could post that I like Radiohead, or bought a Radiohead album or attended a Radiohead concert.
But if I'm listening to Radiohead right now, I would want my followers to see that for a certain amount of time, and then stop seeing it when it expires. I could watch a movie for 2 hours, or listen to a song that expires after 5 minutes.
Does anyone think that a single post type should be used for Right Now posts? Or could posts have fields to indicate if it is current for a specified period?
I'm not sure whether visiting https://tent.io/types/post/status/v0.1.0 should show the actual definition of a Post Status, but to me, http://tent.io/docs/server-protocol makes it sound like it should.
A domain and DNS should be the only requirements for Tent discovery, via DNS TXT records.
HEAD and link discovery require integration with WWW. Instead, consider a TXT record that allows one to indicate the location of their Tent server without integrating Tent into their web stack (or lack thereof).
Better decoupling of Tent from WWW makes easier work for would-be Tent hosts, where they don't need to a) host WWW for users, or b) require users' WWW hosting to refer to their Tent service. Instead, users create a TXT record pointing at their Tent host and they're all set, without needing to worry about managing a WWW presence and keeping it synced with their Tent presence.
An app should be able to send notifications to a user. The user can then read the notification (and associated data) on another app and 'mark it as read'/discard it.
I don't read HN, but since I saw so many tweets about Tent, I went and checked out the thread. How do you plan on resolving this conflict of interest?
We anticipate follower counts similar to the levels seen on Twitter today. Managing 1 few hundred followers isn't too difficult, thousands can be managed by cranking up the dynos on heroku. But yeah, Justin Bieber is going to need a hosted solution to handle that kind of load (like he has now with Twitter, YouTube, etc).
http://news.ycombinator.com/item?id=4419117
and
hosted service within one month.
http://news.ycombinator.com/item?id=4419414
I'm not sure what incentive there is to reduce complexity in the protocol if you plan on selling a hosted version.
If you really want to be making this standard, going through the standards bodies is probably a good idea.
Hello! I just came accross the tent.io project it looks better than i thought.
My understanding of programming goes to 1996 HTML, some javascript and some actionscript, so i don't think i can help at the technic development part of this tool.
But the theory it's great, and as soon there's the project finished it will help everyone of my face**** friends go away from hell.
Just some activist needs in any tool.
It has to hide your ip, and be able to use proxies.
It has to be able to be Portable.
Will be nice a way to have some of your bitdata hidden at internet, for the program data to appear, being encrypted till then or a similar way to hide information.
An activist needs to have closed secret groups, and hidden info, so no goberment can "Peek" what they share and/or write.
There is a running idea, of a tool to plan tasks, filling up an easy form, to make an activist action possible for anyone, easy create e-mail account, new blog, main stream social networks to make the rest of the people aware of your campaign (if you decide so), choose the rss feeds to curate, and follow a complete manual, action, after action to reach objetives. More or less following tasks similars to the ones included at: http://www.aeinstein.org/organizations103a.html . and adding your own.
An hability to merge databases would be great (embassies and consulates worldwide, who are your representatives, prime ministers... ) Not just internet links, also addresses, phone numbers, faxes...
The Information is a basic for an activist, we need accurated info about whats happening in the world and we cannot trust all media, every activist should be able to have a curating tool to do that, and also not just receive the info they choose to receive, One random new of every five they read, will open their minds and get them new ideas.
There's a need for an alternative economy based on resources, time and knowledge, not in money, more inclusive, respetuous, and work with solidarity.
I know all this is hard to implement, and requires a lot of energy, tell me what you need to do this and i will try to help you achieving it.
Also once the Social Network it's finished, i will help with the diffusion, i really think it's what every activist needs.
It's not clear to me how this is actually better than ostatus. This may be just because I've really only skimmed things so far, but having some sort of section to compare tent to existing protocols would be cool.
It seems the PATCH operation requires you to specify all groups, the old ones as well? So its not actually a PATCH but a PUT operation.
You should consider implementing TASK based operations, to avoid this problem
PATCH /following/{id}/add-group
PATCH /following/{id}/remove-group
Using PUT operations here makes the system prone to lost updates, given disconnected clients and eventual synchronization.
Hi there,
Since you are building a protocol, consider these options:
Using a custom content type could help work around some of the versioning issues. See the corresponding RFC for vendor MIME types: http://tools.ietf.org/html/rfc4288#section-3.2
MIME types also can have parameters. This could be used like
Accept: vnd.example-com.foo+json; version=1.0
Standard JSON and JavaScript coding style uses lowerCamelCase identifiers, not snake_case ones. I know that never makes Rubyists happy, but it's not a Ruby project once you're talking standardization.
Reading through the spec (great work by the way), there doesn't seem to be any way for a server to let an app know that there's a new message. Within the server API for apps could there be a server-sent events URL that 3rd parties could use to listen for new messages?
Considering you have aims to be RESTful, you should really be considering the creation of a media type, which is how most of these standards work. Right now you're serving plain application/json with no context.
Related: #10
The section on "What about the federated social web?" mixes up the federated social web with OStatus and makes some incorrect statements.
"Federated social web" is just a pattern -- a graph of social network servers that can connect to each other in interesting ways. It's different from some social platforms (Twitter, Facebook) in that there's no privileged node in the graph.
tent.io is a federation protocol.
You say, "Because private messages (and many other important features) are beyond the scope of most federation protocols, users can not send private messages to users of other Social Service Providers."
That's true of OStatus; I'm pretty sure it's not true of Diaspora*. I'm not sure "most" makes sense here.
I've just noticed the example of the post with attachments repeats name="photos" as it's field name.
Is this intended or just a typo? As it will prove problematic for some frameworks left as is.
I was rather impressed with XMPP and its extensions. However, in your overview you mentioned that you had surveyed several other protocols before deciding to write tent.io. I'm curious - what shortcomings did you find in XMPP and its extensions that you are attempting to address in tent.io?
Thanks in advance,
.
From RFC 5988:
Applications that don't wish to register a relation type can use an
extension relation type, which is a URI [RFC3986] that uniquely
identifies the relation type.
This is important because relations are supposed to be globally unique.
The first example violation of this I found was here, with
<link rel="tent" href="https://tent.titanous.com" />
This should probably be
<link rel="http://tent.io/rels/tent" href="https://tent.titanous.com" />
or some other similar URI you pledge to keep stable.
Hello,
do you plan ton maintain several implemantation for tent.io server i.e (Java, Ruby, Python) ?
Or Ruby will be the only official language and other implementation will be let to community ?
A similar question for client app ? will you plan to centralize (release) a reference client for tent.io for several OS (Win,n*x,Android,...) or not ?
It appeared you’re missing an awesome logo, so I made you one:
It’s based on the stable triangular shape of a tent, with the corners having further connections.
Also works good in wide:
And on black:
Or on anything for that matter. Here with Beardmore Glacier, one of the earliest routes explorers took to the south pole:
Let me know what you think.
One of the reasons that OpenID failed so hard was that they used URIs for identity; users are much, much more familiar with an email as an identifier.
WebFinger is one sample standard that may help here.
Hello, I have a logo concept for Tent, and it'll be lot of work if I need to make it formal. So I draw some sketchs for showing purpose.
The core concept is simple. We need a symbol like twitter's @. This is the most important part which make a brand work. So I just simply change the letter a to t.
At the same time. the t symbol looks likes faces. When we draw comics, we always draw this symbol to stand for anonymous people.
When grouping the t symbols into a triangle or a chat bubble. It'll become the final logo for tent.io and tent.is.
As above (The MIT Media Lab logo). This concept do not create a solid logo too. The logo can be dynamic. The logo can be everything.
I have a personal project right now and have little time to do other serious stuff. So I share my concept here. If you like my concept and having spare time, you can do it for the tent project if you like. Like tent says, tent is a open project, so I think opening this concept will work, too. I wish the project all my best.
Hope you guys enjoy it. Thanks.
If I miss out on an update, the server 'should' send some stuff later. But if it doesn't I'm SOL. If there was a feed somewhere, I could update my client with what's been going on since I was down.
Activitystrea.ms may be helpful here.
I'm bringing this up again from #6, but I feel this is very important.
As of now, Tent canonical entity names can be arbitrary URIs. There are two parts to a URI that are irrelevant in this case.
/types/info/core version field.Also, other parts of the URI (like authentication data) are meaningless. The only thing that really matters within the URL is the domain name. So why not use that instead of the full URI?
What I am talking about is the entity field below, the servers field uses URLs for a reason (although it should probably be specified that a path MUST NOT be present there.)
{
"https://tent.io/types/info/core/v0.1.0": {
"licenses": [
"http://creativecommons.org/licenses/by/3.0/"
],
"entity": "https://example.org",
"servers": [
"https://tent.example.org",
"http://eqt5g4fuenphqinx.onion/"
]
},
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 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.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
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.