Re: VC-HTTP-API - A follow up on the RAR presentation

Very well said Moses! I'm a rather convicted *occupy* with an *if** we
build it* alter ego. And I'd be lying if I said I didn't have dreams
of *selling
out*, but they're typically accompanied by a trojan horse which seems to
help me sleep at night.

With you on the lambo, but more of a Hallberg-Rassy 44 kinda guy ⛵️

On Thu, Jul 8, 2021 at 2:58 PM Kim Hamilton <kimdhamilton@gmail.com> wrote:

> Tag yourself, I’m “occupy identity” with a healthy dose of “if we build it”
>
> On Thu, Jul 8, 2021 at 1:13 PM Moses Ma <moses.ma@futurelabconsulting.com>
> wrote:
>
>> Thanks Dan!
>>
>> I guess I'm just a big ole hippie on the inside. Group hug now!
>>
>> By the way, I really wanted to thank Adrian for his cruise ship example,
>> and that review of the Excelsior Pass. Great stuff!
>>
>> Moses
>>
>> PS, it sure would be great if Dave, Manu, Adrian and some of the others
>> could spread some love and appreciation around in reply to this thread.
>>
>>
>>
>> On 7/8/21 12:01 PM, Daniel Hardman wrote:
>>
>> First of all, huzzah! to Moses for being positive and complimentary. And
>> thank you for the chuckle about the lambo.
>>
>> Thank you, too, Dave, for your clarification. I apologize if my comment
>> came across as impugning your motives. It appears that this was the case,
>> at least for some readers, and I regret it.
>>
>> As far as Dave's analysis, I agree with parts, and disagree with parts.
>> But debating it won't be constructive at this point, so I'll just let it
>> stand as an intelligent POV that I can't fully align with..
>>
>> My larger point -- and what got me feeling defensive -- was about the
>> narrative that there have been no crisp articulations of power imbalance
>> concerns with this group's approach to standardizing credential exchange.
>> That is simply not true. There *have* been crisp articulations with clear
>> examples and concrete counter-proposals. I thought my suggestion
>> was modest: to reframe the design space as broader than HTTP -- WITHOUT
>> asking anyone to implement a single line of non-HTTP functionality. (And I
>> thought I framed my suggestion not as an "Occupy!" one, but in terms of the
>> need to integrate VCs with offline digital cash -- a need being
>> investigated by an estimated 70% of the world's governments right now
>> <https://hackernoon.com/cbcd-19-countries-creating-or-researching-the-issuance-of-a-digital-decentralized-currency-b57a609e695b>...
>> Yet I think I was still seen as a wild-eyed revolutionary. Sigh.)
>>
>> The group chose not to accept my ideas, and I suppose that's a legitimate
>> outcome since majority rules. But having made that choice, it is unfair to
>> now claim ignorance to the tradeoffs that have been made. All the issues
>> that Adrian is mentioning are tradeoffs implied by the HTTP-centric
>> approach you chose. The narrative that should ensue is "We've given these
>> concerns a fair hearing and chosen not to address them," rather than the
>> you-have-yet-to-demonstrate-why-and-how-and-the-burden-of-proof-is-on-you
>> narrative I was hearing.
>>
>> --Daniel
>>
>> On Thu, Jul 8, 2021 at 7:39 PM Dave Longley <dlongley@digitalbazaar.com>
>> wrote:
>>
>>>
>>> On 7/8/21 6:55 AM, Daniel Hardman wrote:
>>> > Indeed, the way I received Dave Longley's response to my concern was
>>> > essentially, "I don't care about those problems because they're not use
>>> > cases of my customers. If somebody besides online institutions wants a
>>> > standard for credential exchange, let them find their own money and
>>> > write their own standard." (Note my careful language "the way I
>>> > received" -- I may have received it wrong. I'm not claiming my
>>> > perception is objective reality--only that I received it that way.)
>>>
>>> You did receive it wrong and I'm sorry for miscommunicating my point.
>>> Unfortunately, it was at the end of the call so there was no time for
>>> clarification. We all want a more equitable future. I do ask for more
>>> assumption of good intentions on the behalf of others here. This future
>>> is important to all of us -- despite your comment that made it seem like
>>> I did not care. I just think my approach is more likely to see success
>>> than how I perceive what you presented as an alternative.
>>>
>>> My point was:
>>>
>>> 1. Funding sources for new technology will go elsewhere if you put too
>>> much of a burden in front of them. Then no progress toward our common
>>> goals will be made.
>>>
>>> 2. I believe we are more likely to see success when we work to evolve
>>> existing ecosystems rather than try to invent separate ones that must
>>> be adopted wholesale ("build it and they will come"). We must make the
>>> on-ramp slope flat enough to ensure newer, more equitable technologies
>>> are adopted by existing companies and users.
>>>
>>> 3. People are asking others to do free work and/or take on very high
>>> risk for them -- and they seem to be unaware of it ("*you* build it and
>>> they will come"). Telling those people that they *only* care about money
>>> and/or "institutional customer" use cases comes across to me as cheap
>>> virtue signalling and, I'm sure to others, as offensive.
>>>
>>> Every little piece of SSI technology that is adopted by existing
>>> companies helps change the culture to support more SSI technology. To
>>> me, that means we need to have an architecture that allows that sort of
>>> adoption.
>>>
>>> If "SSI technology" is just a giant stack that you have to embrace all
>>> at once -- I think we will fail. I *do* say to people who rigidly
>>> believe that's the only way forward -- to find their own funding and
>>> create their own standard. That part of what I said you may have
>>> received correctly, but the above context wasn't fully there. Hopefully
>>> it is clearer now. I, for one, will not work on an approach that I think
>>> ultimately harms our shared cause. That does not mean that I question
>>> the motives of those taking that approach.
>>>
>>> Slow progress is not failure. In fact, it is often the only alternative
>>> to no progress at all. I believe that it's easy to create barriers
>>> in software design that are high enough to cause entire projects to
>>> collapse on their own weight, resulting in no progress. It is especially
>>> easy to do this when there is insufficient focus on creating near term
>>> value. This is how I view some of the technological offerings I've seen
>>> in this space.
>>>
>>> It isn't that I think their end goal isn't laudable -- it's that I think
>>> those approaches are more likely to be *barriers* to achieving those
>>> goals rather than catalysts.
>>>
>>> In short, the way you received my comment was the opposite from how I
>>> intended it -- and for my poor choice of words, I apologize.
>>>
>>>
>>> --
>>> Dave Longley
>>> CTO
>>> Digital Bazaar, Inc.
>>>
>> --
>> *Moses Ma | Managing Partner*
>> moses.ma@futurelabconsulting.com | moses@ngenven.com
>> v+1.415.568.1068 | skype mosesma | allmylinks.com/moses-ma
>> Learn more at www.futurelabconsulting.com. For calendar invites, please
>> cc: mosesma@gmail.com
>>
>