So I have built one, I'am using couchbase p2p to distribute an encrypted nosql database that can be shared even over bluetooth and all torrent files are stored in the couchbase attachments so its not even magnet link based but you can distribute those essential torrent files. The webtorrent protocol is used to scale to platforms such as ios and web where no torrent client is available as of yet.
join me at starpy dot me
Topic: Blockchain-based torrent tracker? (Read 4772 times)
combine with this: https://bitcointalksearch.org/topic/m.1495784 and you have a decentralized facebook kind of thing
Each Nym could have however many links fit into allowed data size (and historic linkages using name_history), and Nyms get reputation rating with upvoting via namecoin sendtoname function. Any user could command control if as many reputable Nyms they like.
Right, that's the approach I've been suggesting. I think it should work. 
Code:
namecoind name_new fs/somecoolmovie
Code:
namecoind name_firstupdate fs/somecoolmovie ''
Hmm, yeah you're right about that ... so maybe have the user put there PseudoNym in the name field so it can gain trusted-rep for posting authentic links and have one of the fields in value describe the file content in human-recognizable, searchable form?
Code:
namecoind name_new fs/filesharedude
Code:
namecoind name_firstupdate fs/filesharedude '{.... "vd": "some_cool_video" ... "ad":"some_cool_audio" ...}'
(plus map to hash value/link)
Each Nym could have however many links fit into allowed data size (and historic linkages using name_history), and Nyms get reputation rating with upvoting via namecoin sendtoname function. Any user could command control if as many reputable Nyms they like.
Code:
namecoind name_new fs/somecoolmovie
Code:
namecoind name_firstupdate fs/somecoolmovie ''
Quote
This does seem to indicate however that namecoin isn't needed for storing information since the DHT already has it. Maybe the namecoin provides the "unique identity that can be followed to provide files I'm interested in" aspect.
Namecoin can provide the unique ID look-up to the DHT and the sendtoname facilities that are the most crucial and subject to censhorship ...
this is a great idea and application for namecoin btw.
Edit: also suggest use general namespace id "fs" (fileshare)
e.g.
Code:
namecoind name_new fs/somecoolmovie
Code:
namecoind name_firstupdate fs/somecoolmovie ''
and etc.
a website? I thought the whole point was doing it without a website. what about a beautiful command line tool? or a simple gui app?
Yeah, command line tool/gui would be good. A website with a read only view would be good for initial uptake though for those not wanting to install namecoin just to see what it's all about. Isn't this the kind of thing namecoin should work well for?
-MarkM-
-MarkM-
Given that the blockchain is compatible with btc it is not a question which one could but which one should. Great idea if you ask me but I can see a lot of hate coming from purists vetoing use of btc blockchain for storage - makes sense. With that in mind it'd be really cool to see someone try this with namecoin chain or testnet.
I've created a "btm/testing" name for testing. It should show in about block 93985 where you can see it the magnet links it has posted with:
You can list the "btm/" namespace with:
hehe I got it.Code:
namecoind name_history btm/testing
You can list the "btm/" namespace with:
Code:
namecoind name_filter "^btm/.+"
You have set up something like a youtube channel.
That is quite short- magnet links for example, for movies at popular torrent sites however are many times longer then that. I'd post here an example except for obvious reasons. :-)
As I test I found a long magnet link from a movie site. I took just the hash from that link (the string of hex digits after '?xt=urn:btih:') and searched for that in the DHT network via btdigg.org. This pulled up the correct file information, including a shorter magnet link (without the 'tr' tracker links). This seems to imply that just requiring the hash is fine. I did the same for searching for the archlinux iso (hash e940a7a57294e4c98f62514b32611e38181b6cae) and it came up.This does seem to indicate however that namecoin isn't needed for storing information since the DHT already has it. Maybe the namecoin provides the "unique identity that can be followed to provide files I'm interested in" aspect.
I didn't know about BTdigg, indeed that sounds like the've already solved the question we were asking. Although perhaps the namecoin blockchain- being merge mined with Bitcoin is more robust?
one advantage I see with this besides being totally nerdy is that you can build some reputation for your "channel".
There are some other threads/links about this subject, please check out:
http://dot-bit.org/forum/viewtopic.php?f=5&t=613
https://bitcointalksearch.org/topic/the-pirate-bay-as-blockchain-127980
rgds
http://dot-bit.org/forum/viewtopic.php?f=5&t=613
https://bitcointalksearch.org/topic/the-pirate-bay-as-blockchain-127980
rgds
That is quite short- magnet links for example, for movies at popular torrent sites however are many times longer then that. I'd post here an example except for obvious reasons. :-)
As I test I found a long magnet link from a movie site. I took just the hash from that link (the string of hex digits after '?xt=urn:btih:') and searched for that in the DHT network via btdigg.org. This pulled up the correct file information, including a shorter magnet link (without the 'tr' tracker links). This seems to imply that just requiring the hash is fine. I did the same for searching for the archlinux iso (hash e940a7a57294e4c98f62514b32611e38181b6cae) and it came up.This does seem to indicate however that namecoin isn't needed for storing information since the DHT already has it. Maybe the namecoin provides the "unique identity that can be followed to provide files I'm interested in" aspect.
I didn't know about BTdigg, indeed that sounds like the've already solved the question we were asking. Although perhaps the namecoin blockchain- being merge mined with Bitcoin is more robust?
That is quite short- magnet links for example, for movies at popular torrent sites however are many times longer then that. I'd post here an example except for obvious reasons. :-)
As I test I found a long magnet link from a movie site. I took just the hash from that link (the string of hex digits after '?xt=urn:btih:') and searched for that in the DHT network via btdigg.org. This pulled up the correct file information, including a shorter magnet link (without the 'tr' tracker links). This seems to imply that just requiring the hash is fine. I did the same for searching for the archlinux iso (hash e940a7a57294e4c98f62514b32611e38181b6cae) and it came up.This does seem to indicate however that namecoin isn't needed for storing information since the DHT already has it. Maybe the namecoin provides the "unique identity that can be followed to provide files I'm interested in" aspect.
interesting, how would the tracker work in this case? Considering how long magnet links are?
Can you give an example of a long link? Here's an example of the archlinux distro:Code:
magnet:?xt=urn:btih:e940a7a57294e4c98f62514b32611e38181b6cae&dn=archlinux-2013.01.04-dual.iso&tr=udp://tracker.archlinux.org:6969&tr=http://tracker.archlinux.org:6969/announce
This is 176 characters. Are the "tr" keys actually needed?
Edit: The only mandatory parameter= required is the 'xt' according to BEP 009. So magnet links can be quite short. A website can scan namecoin for the magnet links then retrieve the metadata via the Bittorrent DHT. I still think it might be good to include metadata in namecoind though to make searching faster/easier. Something like:
Code:
{"hash":"btih:e940a7a57294e4c98f62514b32611e38181b6cae","description":"archlinux-2013.01.04 iso","tags":["linux","iso"]}
That is quite short- magnet links for example, for movies at popular torrent sites however are many times longer then that. I'd post here an example except for obvious reasons. :-)
interesting, how would the tracker work in this case? Considering how long magnet links are?
Can you give an example of a long link? Here's an example of the archlinux distro:Code:
magnet:?xt=urn:btih:e940a7a57294e4c98f62514b32611e38181b6cae&dn=archlinux-2013.01.04-dual.iso&tr=udp://tracker.archlinux.org:6969&tr=http://tracker.archlinux.org:6969/announce
This is 176 characters. Are the "tr" keys actually needed?
Edit: The only mandatory parameter= required is the 'xt' according to BEP 009. So magnet links can be quite short. A website can scan namecoin for the magnet links then retrieve the metadata via the Bittorrent DHT. I still think it might be good to include metadata in namecoind though to make searching faster/easier. Something like:
Code:
{"hash":"btih:e940a7a57294e4c98f62514b32611e38181b6cae","description":"archlinux-2013.01.04 iso","tags":["linux","iso"]}
I've created a "btm/testing" name for testing. It should show in about block 93985 where you can see it the magnet links it has posted with:
You can list the "btm/" namespace with:
Now there needs to be a website that scans that namespace, does a name history on the names, and provides it in a pretty format.
Code:
namecoind name_history btm/testing
You can list the "btm/" namespace with:
Code:
namecoind name_filter "^btm/.+"
Now there needs to be a website that scans that namespace, does a name history on the names, and provides it in a pretty format.
interesting, how would the tracker work in this case? Considering how long magnet links are?
I've created a "btm/testing" name for testing. It should show in about block 93985 where you can see it the magnet links it has posted with:
You can list the "btm/" namespace with:
Now there needs to be a website that scans that namespace, does a name history on the names, and provides it in a pretty format.
Code:
namecoind name_history btm/testing
You can list the "btm/" namespace with:
Code:
namecoind name_filter "^btm/.+"
Now there needs to be a website that scans that namespace, does a name history on the names, and provides it in a pretty format.
not quite sure yet but my gut says the second variant is more likely to succeed
I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}
>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip
Good point about 'sendtoname'. Using a separate protocol per namespace is also a good idea. Given magnet url's have a "dn" key for giving the full name I'm wondering if it's even worth having JSON as the value. Just having the magnet link gives all that's needed.I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}
>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip
aaaand we're done. with namecoin everything is a peace of cake.
If it were not for hen and egg...
edit: I guess the length limit of 520 characters might be an issue with magnet links. maybe we should finally fix this bug to at least have a 1000 characters available.
What about base128 encoding?
Or splitting the tracker over multiple payments?
not quite sure yet but my gut says the second variant is more likely to succeed
I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}
>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip
Good point about 'sendtoname'. Using a separate protocol per namespace is also a good idea. Given magnet url's have a "dn" key for giving the full name I'm wondering if it's even worth having JSON as the value. Just having the magnet link gives all that's needed.I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}
>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip
aaaand we're done. with namecoin everything is a peace of cake.
If it were not for hen and egg...
edit: I guess the length limit of 520 characters might be an issue with magnet links. maybe we should finally fix this bug to at least have a 1000 characters available.
not quite sure yet but my gut says the second variant is more likely to succeed
I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}
>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip
Good point about 'sendtoname'. Using a separate protocol per namespace is also a good idea. Given magnet url's have a "dn" key for giving the full name I'm wondering if it's even worth having JSON as the value. Just having the magnet link gives all that's needed. I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}
>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip
not quite sure yet but my gut says the second variant is more likely to succeed
I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}
>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip
length of the value field is currently limited to 520 characters because of a bug in name_update. It is planned to increase the possible value length to 9000bytes or so.
I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}
>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip
length of the value field is currently limited to 520 characters because of a bug in name_update. It is planned to increase the possible value length to 9000bytes or so.
Jump to: