FEP-d8c8: BitTorrent `Torrent` objects

ActivityPub
1

hello every1, here is a FEP for representing bittorrent .torrents as activitypub/streams objects :slight_smile:

very very simple, just “treat a thing that is already a json-like object as a json object” with some details on encoding binary as strings.

Examples and reference implementation in the FEP!

PR: #714 - FEP-d8c8: BitTorrent `Torrent` Objects - fediverse/fep - Codeberg.org

Fedi Thread: jonny (good kind): "Here's another #FEP for representing torrents on …" - neurospace.live

2

PeerTube puts everything into an url array.

Magnet links are Link objects. Infohashes go to the tag property of a Link.

3

(For others reference, see the example tab here: ActivityPub | PeerTube documentation )

Sure we could just link to the bencoded torrent file, but the point of this is to federate the contents of a torrent file, not just the infohash and magnet link. To make a direct Torrent object that can be extended with other terms and be made a general way of federating data.

The infohash can be a tag in a Link, when the torrent itself is just a Link. However this defines a Torrent object which has an infohash as one of its properties, as any other object might.

The magnet link can be made into a Link object, thats no prob, although I dont know what benefit that would have, semantic or functional.

4

Yes, I understand that Torrent object is supposed to be extendable, but why not add url property to it like PeerTube does? The benefit is that you can use standard properties instead of introducing new ones.

5

It's always better to use standard properties because that enables interoperability. For example adding content and url would make your Torrent compatible with my software without any changes on my side.

6

Yes indeed, thats why this FEP is trying to establish standard terms where previously there were only ad-hoc ones!

I’m not quite sure what you mean, which url/content fields and containing what?

7

A Torrent object could look like this:

{
    "id": "https://example.com/torrents/mytorrent123",
    "type": "Torrent",
    "content": "Description of a torrent",
    "infohash_v2": "d655cc657b0b56975c2596ef1c493055565daccaf2ae29cafdea22bd7cc80e6a",
    "url": [
        {
            "href": "magnet:?xt=urn:btmh:d655cc657b0b56975c2596ef1c493055565daccaf2ae29cafdea22bd7cc80e6a&tr=http%3A%2F%2Fexample.com%2Fannounce",
            "rel": "alternate"
        }
    ]
}
8

ok, if that is a standard way to represent urls i could do it that way. any prior art i can cite?

edit: if we are making it an object, is there a standard way to do mime/etc. type? having multiple types of related entities like CIDs and etc. would be nice to have too

9

any prior art i can cite?

PeerTube. The usage of url is not documented on their site, so here's an excerpt from a real Video document:

{
  "id": "https://peertube.cpy.re/videos/watch/da2b08d4-a242-4170-b32a-4ec8cbdca701",
  "type": "Video",
  "url": [
    {
      "href": "https://peertube.cpy.re/w/sWxgbBUu1ScQkHqz831Qqi",
      "mediaType": "text/html",
      "type": "Link"
    },
    {
      "fps": 15,
      "height": 1044,
      "href": "https://peertube.cpy.re/lazy-static/torrents/da2b08d4-a242-4170-b32a-4ec8cbdca701-1044.torrent",
      "mediaType": "application/x-bittorrent",
      "type": "Link",
      "width": 1920
    },
    {
      "fps": 15,
      "height": 1044,
      "href": "magnet:?xs=https%3A%2F%2Fpeertube.cpy.re%2Flazy-static%2Ftorrents%2Fda2b08d4-a242-4170-b32a-4ec8cbdca701-1044.torrent&xt=urn:btih:bab24aa0a1cf3d44b4203d5f055468b919ec7400&dn=PeerTube+demo+with+Mastodon&tr=https%3A%2F%2Fpeertube.cpy.re%2Ftracker%2Fannounce&tr=wss%3A%2F%2Fpeertube.cpy.re%3A443%2Ftracker%2Fsocket&ws=https%3A%2F%2Fpeertube.cpy.re%2Fstatic%2Fweb-videos%2Fda2b08d4-a242-4170-b32a-4ec8cbdca701-1044.mp4",
      "mediaType": "application/x-bittorrent;x-scheme-handler/magnet",
      "type": "Link",
      "width": 1920
    }
  ]
}

I don't know if these MIME types are standard, but they are used by some torrent applications.

10

i know that application/x-bittorrent is widely accepted. maybe it would be worth having a separate spec for the use of the url prop too

1 Like
11

@silverpill i guess one question is what the semantics of url would be compared to e.g. alsoKnownAs - like it looks like they are using url to mean “different versions of the same thing” with additional qualifications like mime type and extra metadata for different encodings, which traditional skos-like terms don’t really capture well. like technically all things in linked data are either a literal or a URI, so a url field is a bit ambiguous of a name, but i like the thing that peertube is doing with it and think it’s better than having a term for every possible kind of other representation like the current text of the FEP does with bencoded

1 Like
12

According to AS vocabulary, url "Identifies one or more links to representations of the object", which seems to fit.

alsoKnownAs, on the other hand, is often used to point to a different object. I think it should be reserved for migrations.