- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Mon, 2 Sep 2013 19:33:21 +0200
- To: Michael Powers <michael@mpowers.net>
- Cc: Web Payments <public-webpayments@w3.org>, Steven Rowat <steven_rowat@sunshine.net>
- Message-ID: <CAKaEYhK+70-=rJsT_KobSPKfstgz8a3HK9FsSx1byP=0=rfDsg@mail.gmail.com>
On 2 September 2013 18:30, Michael Powers <michael@mpowers.net> wrote: > I read through this thread with interest. > > Let me first explain very simply what we're proposing: > > 1. Extend RSS/Atom to support self-signed and/or self-encrypted entries. > 2. Specify a convention for requesting and relaying RSS entries using > plain-old HTTP(S). > 3. There is no step 3. > > The interesting bit for this list is: > - the globally unique identifier for an RSS feed is also its public key. > - if that public key is a crypto-currency payment address, then all kinds > of interesting things can happen with regard to content monetization. > This sounds great! I dont think it would be impossible to add signatures to RSS/Atom, maybe even RSS 1.0 can do it already with HTTP signatures. So every user has one or more accounts, and each account has exactly one keypair and exactly one RSS/Atom feed Sometimes the devil is in the detail ... how exactly do you define user / account / key pair. The danger here is that it's defined in some A) restrictive way that creates balkanization B) is defined in some non standard way that lacks adoption / tooling I'm guessing key revocation is not in scope here ie if your key is tightly bound to your account, losing your key means losing your account, also key management is a challenge on clients > > Other projects (diaspora, pump.io, tent, et al.) are focused on new > protocols and architectures. That said, they can easily adopt RSS and HTTP > conventions above. That these other projects have not been successful is > not an unfair criticism of Trsst. We believe we are the maximizing the > possibilities of adoption through embrace of existing standards. > > Importantly: the chicken-egg problem (who will use your social net if no > one is using your social net?) is solved via RSS: all trsst users can > immediately follow any RSS feed, and any RSS reader can follow any trsst > user. And as you can see, as diaspora has learned, an ancillary advantage > to the Kickstarter platform is its ability to pre-generate and sustain > interest in a way that the build-it-and-hope-they-will-come approach has > not. > > If you agree with our principles and approach, I ask you to consider > supporting our project. > > > http://www.kickstarter.com/projects/1904431672/trsst-a-distributed-secure-blog-platform-for-the-o > > Funds are to be used for standardization of above (this is a w3 list, > right?) and development of the reference implementation under as FOSS. I'm > happy to answer any questions here. > There would be a few community groups interested in standardization here, I think. Community groups are informal gatherings of like minded individuals hoping to share and build on existing work. If there are compelling use cases, community groups are designed to be able progress through the W3C standardization process The trsst white paper is a good start: http://www.trsst.com/paper/ I understand it's still in very early stages, but it would be good to discuss a few more of the details, to see if this is some common ground, or some existing work that can be reused > > Best regards, > > Michael Powers > > http://trsst.com > > > > I read through this and then his (Michael Powers) "Trsst" Kickstarter > > page. > > > > > > > http://www.kickstarter.com/projects/1904431672/trsst-a-distributed-secure-blog-platform-for-the-o > > > > > > I found it a comprehensive presentation, I admit to being excited > > about the possibility: it seems it could bring the following things > > together: > > --encryption of all our communications (no government/corporate snooping) > > --an open sourced Facebook/Twitter replacement (no corporate control > > of social web) > > --Bitcoin integration into sales of blogs etc. (micropayment with > Bitcoin) > > > > That's a huge chunk, and would, as Michael says, change the world -- > > if it worked. But of course we're dealing with a code-writing promise. > > > > So I'd like at least some other people on this list, who know much > > more about the technical problems, to look at this and give an opinion. > > > > My main two questions then would be: > > 1. Is it feasible; and if so: > > 2. Should what the web-payments list is attempting be integrated into > > it from the start? > > > > I'm willing to put $ into the kickstarter if others think this is an > > important idea and should be supported. > > > > Steven Rowat >
Received on Monday, 2 September 2013 17:33:49 UTC