Namecoin Twitter
Posted: Fri Mar 28, 2014 3:06 pm
Namecoin Twitter
I open this thread to discuss more about some technical aspects of this (eventually)project, how can be realized and if it can be realized.
Comments if Twitter and/or Namecoin Twitter have social sense please post in the other thread:
http://forum.namecoin.info/viewtopic.php?f=2&t=1716
Some possible questions, brainstorming subjects:
What name should have Namecoin Twitter?
Some suggestions please. For ex. Nitter from Namecoin Twitter
Suggestions for logo eventually.
What we need to store and where ?
I will examine from from the following aspects: censorship and hack resistance, space needed in the blockchain, costs for the tweet owner,
security implications for non tweeting nodes, limitations by the number of followed tweet identities, limitations by the length of message.
-- tw/tweetname - the name entry how it is registered
-- id: here can stay just a pseudonym, a real name or a Namecoin ID which will show more details about the tweet owner, stored in the
blockchain
- sig: here should be a signature from the tweet owner, stored in the blockchain
The tweetname entry is stored decentralized in the blockchain and cannot be seized, hacked or deleted only by the owner.
-- fol: the tweetnames of those who are followed
a. stored in the blockchain:
- calculating with 9-10 character average length for a tweetname about 100 tweetnames can be followed
(when the 1k limit will be fixed, otherwise 50) however anybody can have unlimited number of followers
- the followed tweetname list is highly secure against censorship or hacking
- some costs by updating the tweetname list
- blockchain increase
b. stored outside of the blockchain:
- the number of followed tweetnames is almost unlimited and anybody can have unlimited number of followers
- the followed tweetname list is less secure against censorship or hacking(this can be improved finding a distributed, decentralized and redundant external storage method)
- no costs by updating the tweetname list
- no blockchain increase
-- msg: actual tweet message
a. stored in the blockchain:
- length limitation is not a problem as it is not intended for long messages but it can further decrease the maximal number of followed tweetnames
- some costs by updating the message
- blockchain increase
- the message is stored highly secure against censorship or hacking and more difficult to block readers
- security implications for non tweeting nodes which are in a country with an oppressive regime as there could be some critiques to the
regime(could be reduced with encryption)
b. stored outside of the blockchain:
- no length limitation but if we follow the Twitter model then the message length should be still limited
- no costs by updating the message
- no blockchain increase
- the message is stored less secure against censorship or hacking and reading can be blocked more easily(this can be improved finding a distributed, decentralized and redundant external storage method)
- security implications for non tweeting nodes which are in a country with an oppressive regime as there could be some critiques to the regime
- no security implications for non tweeting nodes
Now I will analyze some storage methods outside of the blockchain:
1. Central storage on a server:
- easiest to maintain
- this would be in a heavy contrast with having the tweetnames in the blockchain as a censorship resistant storage and the content to let totally vulnerable
I wouldn't recommend it to use, eventually only for testing.
2. Redundant storage on more servers in different countries.
The tweets should be stored on every server with their hashes.
Loading a tweet the hashes on the different servers must be compared and only when a majority of identical hashes is achieved the corresponding tweet will be shoved as valid tweet.
The list of the tweet server addresses can be managed like the Bitcoin or Namecoin starting nodes in the client.
Hijacked servers should be fixed or deleted from the valid server list from time to time.
At the beginning could be used some manual server update. Later it should be developed a decentralized content management where tweets not conform with the majority of hashes are replaced and completely hijacked servers are replaced.
Retroshare could be used also to synchronize content between servers and eventually some private computers also.
http://forum.namecoin.info/viewtopic.php?f=5&t=1089
3. A completely p2p solution eventually with some kind of bittorent content storage.
http://forum.namecoin.info/viewtopic.php?f=9&t=1552
I open this thread to discuss more about some technical aspects of this (eventually)project, how can be realized and if it can be realized.
Comments if Twitter and/or Namecoin Twitter have social sense please post in the other thread:
http://forum.namecoin.info/viewtopic.php?f=2&t=1716
Some possible questions, brainstorming subjects:
What name should have Namecoin Twitter?
Some suggestions please. For ex. Nitter from Namecoin Twitter
Suggestions for logo eventually.
What we need to store and where ?
I will examine from from the following aspects: censorship and hack resistance, space needed in the blockchain, costs for the tweet owner,
security implications for non tweeting nodes, limitations by the number of followed tweet identities, limitations by the length of message.
-- tw/tweetname - the name entry how it is registered
-- id: here can stay just a pseudonym, a real name or a Namecoin ID which will show more details about the tweet owner, stored in the
blockchain
- sig: here should be a signature from the tweet owner, stored in the blockchain
The tweetname entry is stored decentralized in the blockchain and cannot be seized, hacked or deleted only by the owner.
-- fol: the tweetnames of those who are followed
a. stored in the blockchain:
- calculating with 9-10 character average length for a tweetname about 100 tweetnames can be followed
(when the 1k limit will be fixed, otherwise 50) however anybody can have unlimited number of followers
- the followed tweetname list is highly secure against censorship or hacking
- some costs by updating the tweetname list
- blockchain increase
b. stored outside of the blockchain:
- the number of followed tweetnames is almost unlimited and anybody can have unlimited number of followers
- the followed tweetname list is less secure against censorship or hacking(this can be improved finding a distributed, decentralized and redundant external storage method)
- no costs by updating the tweetname list
- no blockchain increase
-- msg: actual tweet message
a. stored in the blockchain:
- length limitation is not a problem as it is not intended for long messages but it can further decrease the maximal number of followed tweetnames
- some costs by updating the message
- blockchain increase
- the message is stored highly secure against censorship or hacking and more difficult to block readers
- security implications for non tweeting nodes which are in a country with an oppressive regime as there could be some critiques to the
regime(could be reduced with encryption)
b. stored outside of the blockchain:
- no length limitation but if we follow the Twitter model then the message length should be still limited
- no costs by updating the message
- no blockchain increase
- the message is stored less secure against censorship or hacking and reading can be blocked more easily(this can be improved finding a distributed, decentralized and redundant external storage method)
- security implications for non tweeting nodes which are in a country with an oppressive regime as there could be some critiques to the regime
- no security implications for non tweeting nodes
Now I will analyze some storage methods outside of the blockchain:
1. Central storage on a server:
- easiest to maintain
- this would be in a heavy contrast with having the tweetnames in the blockchain as a censorship resistant storage and the content to let totally vulnerable
I wouldn't recommend it to use, eventually only for testing.
2. Redundant storage on more servers in different countries.
The tweets should be stored on every server with their hashes.
Loading a tweet the hashes on the different servers must be compared and only when a majority of identical hashes is achieved the corresponding tweet will be shoved as valid tweet.
The list of the tweet server addresses can be managed like the Bitcoin or Namecoin starting nodes in the client.
Hijacked servers should be fixed or deleted from the valid server list from time to time.
At the beginning could be used some manual server update. Later it should be developed a decentralized content management where tweets not conform with the majority of hashes are replaced and completely hijacked servers are replaced.
Retroshare could be used also to synchronize content between servers and eventually some private computers also.
http://forum.namecoin.info/viewtopic.php?f=5&t=1089
3. A completely p2p solution eventually with some kind of bittorent content storage.
http://forum.namecoin.info/viewtopic.php?f=9&t=1552