Skip to content
This repository has been archived by the owner on Dec 31, 2020. It is now read-only.

Tent URL Scheme

Jump to bottom
tobiastom edited this page Dec 8, 2012 · 34 revisions

This document will try to define what exactly a potential Tent URL Scheme could be used for.

Alternative 1 - Votes: 0 (edit the page to add your vote)

Follow an entity

tent://follow?<entity_full_uri>

Unfollow an entity

tent://unfollow?<entity_full_uri>

View an Entity’s profile

tent://profile?<entity_full_uri>

View an Entity’s post

tent://posts
  ?<entity_full_uri>
  &<post_id>

New Post

More on what can be included in POST query see in tent-schemas

tent://post
    ?type=<post_type>
    &content=<post_content>
  [ &mentions=<entities_list> ]
  [ &published_at=<timestamp> ]
  [ &permissions=
      <public=( true | false )
    [ &( groups=<groups_list> | <entities_list> ) ]> ]
  [ &licenses=<licenses_list> ]
  [ &<all_other_possible_post_properties> ]

Alternative 2 - Votes: 2 (edit the page to add your vote)

Proposed by ^graue: The entity should come first, followed by the resource or action.

tent://<entity_full_uri>
tent://<entity_full_uri>/follow
tent://<entity_full_uri>/unfollow
tent://<entity_full_uri>/profile
tent://<entity_full_uri>/posts/<post_id>
tent://<entity_full_uri>/post?<all_those_post_content_and_details>

This allows links (including mentions) and transclusions from HTML ‘essay’ posts in a natural way.

Fictional example

Just got back from the first Tent conference. <a href="tent://marco.tent.is/posts/ockwsl">Marco Ferreira's talk</a> was my favorite. In addition to him, I got to hang out with <a href="tent://daniel.tent.is">Daniel Siders</a>, and here's a picture: <img src="tent://graue.tent.is/posts/jookxw/attachments/image.jpg">

A webapp can translate those links into https:// URLs for a browser. Actions could still be specified using URIs like tent://someone.tent.is/follow.

Discussion on alternative scheme

Q: Don’t we need to know if the entity URL is http or https?

A: Yes and no. If no http(s) is given in the url, it should default to https. In case https has no entity (or doesn't respond), http is used.

Unfortunately, this proposed scheme of falling back from https to http destroys the security of using https in the first place. If you're an MITM attacker, you just block access to https on the target machine, the Tent client falls back to http, and you proxy to https, spying on and altering the data. A more secure option would be to use a different protocol, like tent-http:// for non-SSL entities.

Alternative 3

This is the summary of a discussion inside the IRC channel. This alternative is a work in progress and still open to discussion. It more or less combines both alternatives from above.

Example

  • x-tents://tobiastom.tent.is – Direct link to my profile, app is supposed to open my profile.
  • x-tents://tobiastom.tent.is#65gz6h – Direct link to a post on my profile, app is supposed to open the post with the ID 65gz6h from my profile.

Scheme

We decided that it might be a good idea to use x-tent and x-tents. Both are prefixed with the ´x-´ to make it obvious that this are not official tent schemes. If at a later point the tent core developers decide to adopt this proposal, the x might be dropped.

x-tent stands for entities that are accessible via HTTP, x-tents is the alternative for HTTPS. The removal of the HTTP or HTTPS protocol was required because they would be opened in the default browser and could not be handled with other applications. As it is quite like HTTP this could provide less confusion.

Entities

An entity will be opened with the exact same URL as the HTTP(s) link, with the protocol replaced through x-tent(s).

Posts

Unique posts can be accessed with the entity, followed by an # and the unique post ID. A # cannot be part of the entity (it would not be send to the server anyways), so it's save to use this.

Actions

We discussed if there is really a need for actions. Follow for example should not be an action. The application should open the profile. The user the could decide of he would likes to follow this entity or not.

The only real action right now would be to create new posts. A possible solution would be:

  • x-tent://intent/<action>?key=value – Applications would need to check if the host part is intent, if it is, the action is defined through the protocol. Appended are all parameters as key-value pair. Known issues: none.

We also discussed some other solution which all had their own issues:

  • x-tent://<action>?key=value – The action as host part. The problem is that we could not distinguish between an entity and an action. Reserved words would be a solution for that. Also having a requirement that actions only can contain [a-z0-9-_] would solve this.
  • x-tent://<postTypeURL>#publish – This could define the exact post type, but it would get quite ugly to append parameters to it: x-tent://tent.io/types/post/essay/v0.1.0?body=lala#publish
  • x-tent-intent://<postTypeURL>?key=value - No known issues, but a separate registered scheme.

Problems

  • Applications can only register for all tent post types, or none. If an application is only able to handle status posts, but the requested post is an image post, the behavior would be undefined. This cannot easily be solved. Registering just x-tent-photo is not an option. Post types are defined as URLs, which might be different: https://tent.io/types/post/photo/v0.1.0 and https://example.com/photo/v0.1.0 define different photo types, which could not be covered by x-tent-photo. A possible solution would be to let the application forward the user to a supporting app, how that might be defined was not covered.
Clone this wiki locally