We've been finding ourselves needing a lot of links on Dat sites. For instance, we want a way to specify the issues board for an app, or a place to pay authors.
We're thinking about adding a links
field to the dat.json to keep this unified.
Approach 1, as an array:
{
"title": "Beaker browser homepage",
"links": [
{"rel": "payment", "href": "https://opencollective.com/beaker"},
{"rel": "author", "href": "dat://taravancil.com", "title": "Tara Vancil"},
{"rel": "author", "href": "dat://paulfrazee.com", "title": "Paul Frazee"},
{"rel": "https://archive.org/services/purl/purl/bll/resource/issues-board", "href": "https://github.com/beakerbrowser/beakerbrowser.com/issues"}
]
}
Approach 2, as an object with the "rel" as key:
{
"title": "Beaker browser homepage",
"links": {
"payment": "https://opencollective.com/beaker",
"author": [
{"href": "dat://taravancil.com", "title": "Tara Vancil"},
"dat://paulfrazee.com"
],
"https://archive.org/services/purl/purl/bll/resource/issues-board": "https://github.com/beakerbrowser/beakerbrowser.com/issues"
}
}
Any opinions?
I may have missed the context, but am curious whether you are trying to have the links defined in
dat.json
be equivalent to Web Links as used in http headers (rfc8288)? Should one be able to convert between the two in either direction?Some notes regarding making a consistent mapping with web links:
anchor
attribute to create a link from another resource? Might be a nice future addition, as it allows specifying links from resources within the dat (though you may also want to be able to define them in subfolders etc.).rel
s. This should not be a problem, as this is equivalent to multiple links, so in approach #2 you would simply duplicate the link for eachrel
.