Practice Cryptography!
Even with all of the cryptologic and cryptographic technology that has existed in the world for the past 60 years, we still don't really know what encryption is good for or how to use it -- or, more importantly, why it's important. Maybe it's time for people and coders to actually start practicing how to use it, like any other skill.Thursday, February 21, 2008
Social networks are, by their very nature, designed to promote interaction between their members. Community sites (such as slashdot.org, blogger.com, furaffinity.net, and any other which provides username/password authentication and inter-user communication), as well as more traditional social networking sites (such as facebook, myspace, orkut, and others of their ilk), are designed to facilitate communications between users.
However, as the large number of these sites continues to grow, and the topics become ever-more more specialized and diverse, requiring the users to come back to the site repeatedly is almost too much of a requirement. This does 'wonders' for ad revenue (i.e., it drops it down to nigh-useless levels), and such sites quickly drop out of the mainstream if the bandwidth bills get too high.
(This looks almost like a contradiction. if the bandwidth bills get too high, there are site visitors. The cost of providing the site, though, almost can't be met by whatever ad revenue can be eked out, when the traffic gets so high.)
One possible solution which hasn't been examined is the possibility of offloading communications costs onto other networks. This would allow users to use clients that they already have -- such as AIM®, MSN® Messenger®, Yahoo!® Messenger®, or any Jabber client -- to keep the systems and clients they already have, and would increase those messenger networks' traffic, thus leading to higher ad revenue for them. The downside, of course, is that these systems don't, generally, want to rely on systems outside of their own for authentication, and generally refuse to support any third-party extension or use of their networks.
OTR (Off-The-Record, with protocol details and an implementation available at http://www.cypherpunks.ca/otr/) is such an extension. However, most of the things that OTR does are based on the idea of not having a Trent involved at all -- not having a community manager or identity manager involved.
I think there's a place for identity/community management as well as non-managed identity.
However, as the large number of these sites continues to grow, and the topics become ever-more more specialized and diverse, requiring the users to come back to the site repeatedly is almost too much of a requirement. This does 'wonders' for ad revenue (i.e., it drops it down to nigh-useless levels), and such sites quickly drop out of the mainstream if the bandwidth bills get too high.
(This looks almost like a contradiction. if the bandwidth bills get too high, there are site visitors. The cost of providing the site, though, almost can't be met by whatever ad revenue can be eked out, when the traffic gets so high.)
One possible solution which hasn't been examined is the possibility of offloading communications costs onto other networks. This would allow users to use clients that they already have -- such as AIM®, MSN® Messenger®, Yahoo!® Messenger®, or any Jabber client -- to keep the systems and clients they already have, and would increase those messenger networks' traffic, thus leading to higher ad revenue for them. The downside, of course, is that these systems don't, generally, want to rely on systems outside of their own for authentication, and generally refuse to support any third-party extension or use of their networks.
OTR (Off-The-Record, with protocol details and an implementation available at http://www.cypherpunks.ca/otr/) is such an extension. However, most of the things that OTR does are based on the idea of not having a Trent involved at all -- not having a community manager or identity manager involved.
I think there's a place for identity/community management as well as non-managed identity.
Archives
2006-02-12 2006-02-19 2006-02-26 2006-03-05 2006-03-12 2006-03-19 2006-03-26 2006-04-02 2006-04-09 2006-04-16 2006-04-23 2006-07-23 2008-01-13 2008-01-20 2008-02-03 2008-02-17 2008-03-16 2008-04-06 2008-05-11
