W3C home > Mailing lists > Public > public-webpayments@w3.org > September 2013

Re: trsst microblogging

From: Joseph Potvin <jpotvin@opman.ca>
Date: Mon, 2 Sep 2013 16:34:26 -0400
Message-ID: <CAKcXiSqA-mXJyi=a8nD9yYOG=ZWArYBfdROm5ZbNOhWjyua0RQ@mail.gmail.com>
To: Steven Rowat <steven_rowat@sunshine.net>
Cc: Michael Powers <michael@mpowers.net>, Web Payments CG <public-webpayments@w3.org>
I expect that my following two comments on the Trsst whitepaper text
are tangential to  the scope this webpayments list, but are
nevertheless relevant to this thread. If preferred, please point me to
a more appropriate location.

RE: "In that these corporations operate with license from and under
the jurisdiction of a government"

I'd suggest:
"In that these corporations operate under the jurisdiction of a government"
The original wording is correct if the word license is taken in its
colloquial sense, but in most cases, corporations operate under
"letters patent" of some sort, which is a different legal concept from
a license. In any case, the word license is not needed in the

RE: "and allows content creators to be compensated for their work"

Two adjustments to suggest:
(a) instead of "allows" use "enables" here -- since the word "allows"
comes with a nuance of some authority, which I presume is not what you
mean.  I believe you mean that it operationalizes, correct?;
(b) The compensation matter is relevant under circumstances where a
royalty or service fee is required, which is not all cases.
Compensation is normally associated with terms of a license, So
overall I'd suggest this phrase be "and enables content creators
associate their work with licensing terms (eg royalty-based';
free/libre; etc.)"

I presume Trsst would use the webpayments standard to handle payments
for such arrangements as royalties, so I suggest leaving the
word/concept "compensation" to whatever licence might make that

Joseph Potvin

On Mon, Sep 2, 2013 at 3:59 PM, Steven Rowat <steven_rowat@sunshine.net> wrote:
> On 9/2/13 9:30 AM, Michael Powers wrote:
>> 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.
> First: Michael, did you accidentally add one too many negatives in "That
> these other projects have not been successful is not an unfair criticism of
> Trsst." (ie., Did you mean to say: "...is not a fair criticism of Trsst.")
> Or is that what you meant to say?
> Also re the Trsst whitepaper: well-written and gave me a good overview of
> the system you're attempting to set up.
> http://www.trsst.com/paper/
> As Melvin commented, the devil is in the detail, but I for one am happy that
> you've put the overview at such an abstract level, because those of us who
> don't write code (or at least in the languages in use here) need that in
> order to understand what is being attempted.
> Since you appear to be at a critical point with Kickstarter -- you might
> make it, you might not -- I'll comment that, from where I sit, what you're
> describing seems exciting and, at least on this overview level, well
> thought-out.
> I'll also say that if this system became successful (or even got to late
> beta) I'd most likely begin experimenting with it as a publishing platform.
> My guess is that others would do the same.
> I'll go one step further, and say that something like this needs to occur.
> Whether we're at a point of being ready for wide adoption I don't know; but
> the NSA privacy revelations have pushed so many people in this direction
> that now might be the time.
> Steven Rowat
Received on Monday, 2 September 2013 20:35:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:24 UTC