0.4 Links

[danielsiders]

Tent 0.4 will remove both mentions and refs in favor of a more flexible and semantic linking and notification system.

Background

Tent 0.1-0.3 used a combination of mentions and refs to link between posts. These two features enabled several types of functionality including:

• forced delivery (delivering a post to another entity even if that entity had not subscribed to the post type)
• recursive post fetching when materializing feeds (fetching "dependencies" -- additional posts that an application would require to display posts in a feed properly)
• inter-entity linking (model conversations in a distributed system with clear links between posts and entities).

This combination was highly flexible but usually required use of both mentions and refs on an individual post and required the application to know how what a mention or ref meant in a particular post type. Most often the intended use was simply to "link" to another object in Tent, either a post or an entity. These fields also helped overload the post metadata.

With the addition of machine-readable post type schemas and server awareness of post content, mentions and refs have become more limiting than useful, so they are being replaced with a more flexible system of links.

Basics

There are four levels of precision in Tent links: entity, post, post version, a field within a post (deep link).

Post type schemas can now tag an object as being a Tent link. Additionally they can also specify whether a notification should be sent to the linked entity by default and a minimum required level of linking precision.

Permissions

Notifications will never be sent to entities who are not included in the post's permissions. Servers will also be expected to support a variety of other measures to protect user control and privacy including entity black and white lists, one time force delivery, etc.

Deep Links

0.4 Supports deep links, meaning that it is now possible to link to a specific field in another post.

Queries

It is still possible to query another entity for posts that link to or receive links from another entity, post, or post version. (More details about queries elsewhere.)

Source Field

A new field will be added to post metadata to compensate for the loss of mentions and refs. This field will explain the purpose for a post being delivered for example, link or the id of the appropriate subscription.

[seanmonstar]

Sounds awesome and useful.

Insert obligatory "you said no client api breakage!" grumbling here.

[danielsiders]

@seanmonstar we're going to keep on breaking things until the protocol is at 1.0 :)

[seanmonstar]

Does this include what you mentioned about links (hrefs) in status posts?
On Dec 23, 2013 1:33 PM, "Daniel Siders" notifications@github.com wrote:

@seanmonstar https://github.com/seanmonstar we're going to keep on
breaking things until the protocol is at 1.0 :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/213#issuecomment-31145143
.

[danielsiders]

@seanmonstar On the protocol side we view all APIs as being in flux until 1.0 (at which point we'll make all sorts of guarantees about API stability). Post types are a little different. Honestly I think we're going to need to see how things shape up with schemas once they're fully specified and we have a versioning/upgrade scheme in place. As far as post types we "control", I don't think we'd make a breaking change to a post type without some sort of versioning in place. There are a few things I'd like to try out with status posts -- longer bodies, additional fields for quotes, attribution, etc. The sanest way to do that is create entirely new post types (and maybe later on include features from those post types in the status v.X. Generally we'd be strongly opposed to changing the format of data that people have already created or sending what amounts to malformed content down the pipe. Resources should be consistent.

So no, I can't really imagine changing the existing post types, but once we hit 0.4 the problem goes away (since servers enforce schemas, schemas are versioned, and each version of a schema is immutable).

[cuibonobo]

I really welcome this change! Honestly, I found that having both mentions and refs was confusing and redundant.