Misplaced Pages

This is an old revision of this page, as edited by Hrmorley3.4 (talk | contribs) at 15:59, 17 April 2021 (Remove unwanted/invalid links). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Magnet URI scheme" – news · newspapers · books · scholar · JSTOR (January 2015) (Learn how and when to remove this message) This article may require cleanup to meet Misplaced Pages's quality standards. The specific problem is: The lists of examples should be better organized; the layout is too haphazard. Please help improve this article if you can. (May 2012) (Learn how and when to remove this message) This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (December 2014) (Learn how and when to remove this message) (Learn how and when to remove this message)

Magnet is a URI scheme that defines the format of magnet links, a de facto standard for identifying files (URN) by their content, via cryptographic hash value rather than by their location.

Although magnet links can be used in a number of contexts, they are particularly useful in peer-to-peer file sharing networks because they allow resources to be referred to without the need for a continuously available host, and can be generated by anyone who already has the file, without the need for a central authority to issue them. This makes them popular for use as "guaranteed" search terms within the file sharing community where anyone can distribute a magnet link to ensure that the resource retrieved by that link is the one intended, regardless of how it is retrieved.

History

The standard for Magnet URIs was developed by Bitzi in 2002, partly as a "vendor- and project-neutral generalization" of the ed2k: and freenet: URI schemes used by eDonkey2000 and Freenet, respectively, and attempts to follow official IETF URI standards as closely as possible. BitTorrent introduced the btmh: protocol in 2020 as part of its BitTorrent v2 changes.

Format

Magnet URIs consist of a series of one or more parameters, the order of which is not significant, formatted in the same way as query strings that ordinarily terminate HTTP URLs. The most common parameter is "xt" ("exact topic"), which is generally a URN formed from the content hash of a particular file, e.g.:

magnet:?xt=urn:btih:c12fe1c06bba254a9dc9f519b335aa7c1367a88a

This refers to the hex-encoded SHA-1 hash (btih, "BitTorrent info-hash") of the torrent file info section in question. Note that, although a particular file is indicated, an availability search for it must still be carried out by the client application.

Parameters

The following parameters are supported:

The standard also allows for application-specific experimental parameters, which must begin with "x."

xt exact topic

The xt parameter specifies the URN for a given p2p protocol. Its purpose is to provide a search parameter for finding the metadata to the torrent. This effectively acts as a replacement to a .torrent file, which itself contains the torrent metadata, by instead searching the p2p network (using the URN) for that metadata. Each protocol handles a URN uniquely; for example, xt=urn:btih:FFC7E738EAA4CD4ECF51EC6FD669C6CDE2C281A8 uses the btih (BitTorrent v1 protocol), so a BitTorrent client can take the hash and lookup the torrent's metadata in the BitTorrent DHT. In the case of DHT the client searches through a set of pre-known nodes and requests the metadata for an infohash; those nodes will make the same request to other known nodes until eventually a swarm is found and returned.

xt also allows for a group setting. Multiple files can be included by adding a count number preceded by a dot (".") to each link parameter.

magnet:?xt.1=&xt.2=

Tiger Tree Hash (TTH)

These hashes are used on Direct Connect and G2 (Gnutella2), among others.

xt=urn:tree:tiger:

Secure Hash Algorithm 1 (SHA-1)

These hash sums are used on gnutella and G2 (Gnutella2).

xt=urn:sha1:

BitPrint

Such hash sums consist of an SHA-1 Hash, followed by a TTH Hash, delimited by a point; they are used on gnutella and G2 (Gnutella2).

xt=urn:bitprint:.

ED2K (eDonkey2000) hash

These hash sums are used on eDonkey2000.

xt=urn:ed2k:

Advanced Intelligent Corruption Handler (AICH)

Not formal URNs for Magnet links, such hash sums are used by eDonkey2000 to restore and control the integrity of downloading and already downloaded files.

xt=urn:aich:

Kazaa hash

Used on FastTrack, these hash sums are vulnerable to hash collision attacks.

xt=urn:kzhash:

BitTorrent info hash (BTIH)

These are hex-encoded SHA-1 hash sums of the "info" sections of BitTorrent metafiles as used by BitTorrent to identify downloadable files or sets of files. For backwards compatibility with existing links, clients should also support the Base32 encoded version of the hash.

xt=urn:btih:

Some clients require Base32 of info_hash (e.g., Vuze).

Message Digest 5 (MD5)

Supported by G2 (Gnutella2), such hashes are vulnerable to hash collision attacks.

xt=urn:md5:

Web links to the file

There are two types of download links that a Magnet link can include as a direct or backup source.

"as" ("acceptable source")

Most clients treat "as" as equal to the "xs" token when it comes to priority, and ignore the timeout before contacting "as" sources denoted by the specs.

Content-Addressable Web URL

This type of RFC 2168-based link is used by gnutella as well as G2 applications.

xs=http://:/uri-res/N2R?

xs=http://192.0.2.27:6346/uri-res/N2R?urn:sha1:FINYVGHENTHSMNDSQQYDNLPONVBZTICF

Link to a DirectConnect hub to find sources for a file

This type of link connects a DirectConnect client immediately to the hub in question.

xs=dchub://:

Reference to a web-based source cache for a file on Gnutella2

In this case, the included link points, not to a client IP or direct source, but to a source cache which stores the IPs of other clients contacting it to download the same file. Once a client connects to the cache, it is served IPs for alternate sources, while its own IP is stored within the cache and forwarded to the next one connecting to the cache. This system operates similar to a BitTorrent tracker.

xs=http://cache.freebase.be/

Reference to an eD2k source

xs=ed2kftp://:///

Supplement format (x.)

For experimental and self-complementing informal options, the prefix x. followed by a chosen suffix letter can be used. These names are guaranteed to never be standardized.

x.=

Clients

See also

• BitTorrent
• Peer-to-peer
• Burnbit
• ed2k URI scheme
• Metalink
• Named data networking
• InterPlanetary File System

Notes

1. ^ dchub://:
2. ^ Passes link to external software
3. ^ adc://:
4. ^ adcs://:
5. Since v2.5.1.0

References

1. "BitTorrent v2". BitTorrent. Retrieved 7 September 2020.
2. ^ BEP-9: Extension for Peers to Send Metadata Files
3. Chapweske, Justin (November 29, 2001). "HTTP Extensions for a Content-Addressable Web". www-talk. W3C.
4. "v1.74 Core Improve: support ws parameter in Magnet URI, to add web seed". bitcomet. bitcomet.
5. "magnet-test.c in trunk/libtransmission; Revision 9531". Transmission.
6. "magnet.c in trunk/libtransmission; Revision 9979". Transmission.

External links

• Magnet-URI Project on SourceForge, an early definition of the format (last update 2002)
• CHK Freeware Checksum Utility with SHA1-Base32 and ED2K support
• RHash on SourceForge, an open source command-line tool, which can calculate Magnet links

• File sharing
• URI schemes