- Metainfo pieces list is actually a list, not a concatenated hex string, because we can select specific hashing algorithms to calculate the piece hashes.
- Although this client does support WebRTC in both the browser and the server, a WS proxy server and Discovery server must be specified. (No data will flow through these servers, it is purely used to allow peers to discover eachother)
- Discovery Server: https://github.com/geut/discovery-swarm-webrtc
- Proxy Server: https://github.com/RangerMauve/hyperswarm-web#setting-up-a-proxy-server
- When saving data to a DHT it is SHA1 hashed as a limitation of bittorrent-dht. So when we use an infosig, it becomes SHA1(YOUR_SIG(YOUR_HASH(METAINFO))) or for infohash its SHA1(YOUR_HASH(METAINFO))
- Cannot use afaik, will not run in browser as it relies on sodium-native.
-
Figure out a nice way to handle streaming chunks in order for consumers
-
Reduce memory pressure by having the piece buffer be backed by disk
-
Smart piece management
-
Rarest Piece first?
-
Retry logic
-
Multiple Peer handling
-
Metadata discovery
-
Become seeder after Metadata discovery
-
Select desired files, not just all files in torrent (Desired Bitfield vs Have Bitfield ?)
-
WebRTC
-
TCP
-
UDP
-
Browser compatibility
-
Node JS Server
-
New Metainfo Spec
-
DHT compatibility (Using Hyperswarm)
-
Signatures in Metainfo
-
Merkel Tree for file pieces hash
-
Nice API for accessing torrents on the fly Torrent.stream, yield Torrent.nextPiece()
-
[] Split Repo to reduce dependencies
Mutable Torrents:
-
In the standard Mutable Torrent spec, it specifies that you should use 1 priv/pub key per torrent (seemingly).
However, the issue with that in regards to this service is that users would need to store many many private/public keys per each file uploaded.
This is a pain in the ass and although it should be possible, it should not be required. -
Instead of 1 keypair per torrent, I propose using a signature of the infohash of the original torrent.
eg. HASH(OriginalInfoSig) -> { NewInfoHash, SIG(NewInfoHash), PublicKey, OriginalInfoSig, seq }- This would allow someone to look up the newest infohash from the original infosig.
- Validate that the NewInfoHash + SIG(NewInfoHash) is valid with the public key.
- Validate that the PublicKey published in the update is the same PublicKey associated with the OriginalInfoSig.
- Use seq to identify what iteration of the torrent we are looking at.
Application Structure:
- Each added Torrent exists within its own scope/lifecycle. (TorrentManager.addTorrent)
- Each Torrent remembers a list of peers (PeerManager) and which pieces it has along with the InfoHash associated
- Observer Pattern, Torrent Manager sits in the middle and recieves events.
- For example, when a new peer is found, the Peer Manager alerts the TorrentManager, to which the torrent manager will ask what pieces they have.
- Or another example, when the UpdateScanner notices there is a new update for a given InfoSig, it will call back to the TorrentManager to get the latest metainfo file and validate which pieces have changed.
- What do you need to seed a torrent?
- Metainfo
- Pieces
- What do you need to leech a torrent?
- InfoHash/InfoSig
- Search for Metainfo from InfoIdentifier (InfoID)
- Search DHT for Peers with the given InfoID
- Use ut_metadata extension to retrieve metainfo
- Start standard TorrentManager with no pieces
- InfoID vs InfoHash vs InfoSig
InfoID is the generic name for either the InfoHash or the InfoSig.
If an InfoSig exists, use that instead of InfoHash.
InfoSig implies a pseudonymous user has uploaded data that may be mutated in the future.
InfoHash is an immutable store of a value.
- WebTorrent Creators
- Bram Cohen
- Bitping Team
- Hyperswarm Team