LinkedIn needs verifiable #TrustedData job history...a green/blue tick equivalent to confirm whether an individual has *actually* worked at a company.

The crazy thing is, @LinkedIn is owned by @Microsoft, which already *owns* the email address service in many companies 🤯

https://twitter.com/fraser_again/status/1641395219286376449

I got contacted by one of recruiters today, saying they wanted a reference from me about an engineer who says they worked @cheqd_io "between May-Dec 2021".

That would have made him the 3rd employee on the team, after me and @fraser_again. One would hope I'd have noticed that. 🙃

Their profile goes on to claim they were a "Senior Cosmos SDK & Solidity Engineer" who "implemented the integration with @veramolabs".

An achievement which is even more impressive, given we hadn't even *launched* our network by then. 🫠 (Also, @EEAnder1 *actually* led this.)

When I told our recruiters that nobody with the name "John" had EVER worked at our company, they doubled down on their lie and said they "worked as an intern under @rosspower".

@rosspower only *wishes* he had an intern 😅 (but it would explain how he's a 10x employee 💪🏽)

Here's the kicker: since a lot of companies use @Outlook as the email service, it would be trivially easy for @Microsoft to allow people to confirm their work email address and issue a portable, digital credential that proves employment history.

This could even work for companies that *don't* use Microsoft, by checking that people can confirm ownership of work emails for the domain that's linked to the company's LinkedIn profile.

And yet, despite having Entra Verified ID, they *still* haven't. 🤷🏽‍♂️ https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-verified-id

We're working at @cheqd_io to work with our partners to enable solutions like these, and many more, to create a #TrustedData ecosystem that adds more trust to online interactions like this - and many more.

You can read the unrolled version of this thread here: https://typefully.com/ankurb/ckj1ayb

LinkedIn badly needs verified job histories

🚨 PSA: If you're migrating away from @LastPass due to their security breach, don't do this, i.e., delete items from your vault and keep your account around. https://www.theverge.com/2022/12/28/23529547/lastpass-vault-breach-disclosure-encryption-cybersecurity-rebuttal?commentID=fdda8faa-b276-4244-9dcd-292fcded4456

This does NOT guarantee that it will be deleted! 😟 (And what you SHOULD do instead 🧵)

LastPass can *only* update your vault when you're logged in to one of their apps.

When you "delete" something in LastPass, it gets moved to a deleted items folder and kept there for 30 days. (This is actually pretty common in most password managers.)

This is designed to prevent credentials/passwords from being lost if they get deleted accidentally, so it's generally a good idea.

*If* your LastPass client remains logged in for the next 30 days, on the 31st day it *actually* deletes these entries and re-uploads a new vault.

However...if your LastPass app gets logged out due to inactivity, or if you explicitly log out because you no longer want it, guess what: LastPass *only* has the vault *with* the credentials in the "deleted" state.

It cannot modify or make changes, including deletion. 😳

In this particular example, LastPass's security model worked *exactly* the way it’s supposed to: any changes to the vault only happen when it’s decrypted.

This can seem counter-intuitive since for *most* other services, a deletion request is (eventually) carried out when asked.

Here’s the kicker: if the person in this example had *actually* deleted their account, rather than keeping it around, the account + the entire vault (along with the deleted/trash folder) would have been deleted.

Keeping the account active is what kept the vault alive.


🧐 So what *should* you do instead, if you're moving away from LastPass?

- If you want to keep your LastPass account active, but with no contents in it, delete your vault's contents AND also go to Advanced Options > View Deleted Items, then choose Permanently Delete All

- If you *don't* plan ever on using LastPass going forward, do the above and then ALSO request an account deletion https://support.lastpass.com/help/delete-your-lastpass-account-lp010012

I recommend BOTH steps and not just skipping to account deletion because asking for your account doesn't always mean it's honoured.

Case in point... 🤦🏽‍♂️👉🏽 https://twitter.com/troyhunt/status/1610008559600930817?s=20


You can read the unrolled version of this thread here: https://typefully.com/ankurb/Jr8hVQa

What NOT to do when deleting your LastPass account...

This is a solid blog post on the identity crisis #SSI industry itself faces, from @rileyphughes. 👌🏾 (Discussion on that thread is very valuable too, for different perspectives.)

It's a challenge we've been mulling over @cheqd_io as well. Some of my own thoughts below (unordered)

https://twitter.com/rileyphughes/status/1595064056993681408?s=20&t=J_wAhAwnJDtpYOfUgucMlA

1️⃣ "IDtech" is overly-broad. It covers what we know as "self-sovereign identity", "SSI", or "Web5"...but it *also* covers traditional selfie-scan-check (e.g., Onfido, Jumio), single sign-on (e.g., Auth0, Okta, Microsoft AD).

The concept of "identity providers" or "identity & access management" is *too* strongly entrenched in the minds of this corner of tech industry as relating to authentication + authorisation.

We need a more *precise* term than IDtech to distinguish it from the broad idea of IAM.

I don't think SSI / Verifiable Credentials *supplants* IAAA (acronym alert! https://thorteaches.com/cissp-iaaa/), it *augments* it. This from actual conversations with clients/architects over many years where they don't really understand why SSI is powerful, until that distinction is made.

2️⃣ "Self-sovereign identity" / "SSI" is a mouthful and too much of an in-crowd term. I like @rileyphughes's points on "reusable" vs "authentic". Similar thread here with @kimdhamilton on alternative terms 👉🏽

https://twitter.com/ankurb/status/1586786749782581251

The more I think of it, the more I get to the conclusion that a constellation of different-but-related terms will need to replace "SSI", at least outside of the in-crowd.

E.g., I can totally see "self-custodied" perform with the crypto crowd, because they love their "not your keys, not your crypto" mantra.

Unsure whether "self-managed" has the same ring to it for general audience, especially since it doesn't have widely-known mantra like above.

3️⃣ "Verifiable Credentials" are "verifiable" in exactly one sense: that it's cryptographically untampered since the point it was issued (or tamper evident).

Where this breaks down is when the term "verifiable" is used with legal/compliance audience, especially as it often gets mangled to "VERIFIED credentials".

In *their* context, "verifi..." means "the data contained within can be trusted". Not whether it's untampered (but false).

Which is why @cheqd_io we played around with "trusted" data or "authentic" data to distinguish "verifiable cryptographically as untampered" (since the data itself could still be "false") vs "cryptographically verifiable AND you can trust it".

Tbh, I don't think either of those takes is *quite* there yet. "Trusted" performs slightly better than "authentic", IMO. Like @rileyphughes, the problem is that the usage of these terms in English just varies so much based on context!

And to answer the question "how many terms have you heard 'verified credential' instead of 'verifiable credential'?" Honestly? Too many times than either I or @fraser_again can count, as soon as we step outside SSI. Especially when talking to teams in large enterprises/govt. 🥲

(For context, I've sat on non-technical standards bodes/panels such as Open Identity Exchange, Tech UK, Fintech Panel etc and a lot of bank teams while at R3, and their interpretation of "verified"/"verifiable is completely different, and the mix-up between the two VERY common.)

The reason why, IMO, that distinction between untampered vs data inside can be trusted comes into play is ultimately it's the latter they care about. I also use it as a *reminder* to those teams that assessing verifiable credentials is *exactly* the same as they assess a PDF

...upload, as far as the legal perspective/liability goes. Yes, an SSI VC will speed up some of the steps/checks by rejecting obvious tampering etc but they still need to trust:

a) data in the credential
b) the issuer

...which is where we run into *trust* registries 🤔

...rules that apply, but rather it's the *portability* that's the key characteristic.

E.g.: I've seen in past few weeks, as people are moving Twitter -> Mastodon, that unscrupulous actors are replicating entire Twitter profiles (with posts) on a different Mastodon server

Having said that..."trusted"/"trustable" over-indexes for the definition of those two terms as defined in traditional KYC/ID verification processes.

But there are other use cases, e.g., porting a social media profile from Twitter to Mastodon, where it's not traditional "trust"

Also, a lot of *technical* engineers/architects, especially if they have any IAM background at all, in my experience find it hard to distinguish "verifiable" (checking the envelope) vs "checking what's inside the envelope". Traditional IAM often cares only about the former.

...than the one the original author created. VCs can enable a form of portability, Obviously, there's no legal/regulatory body that can define a "trust registry" for Twitter (unless they get into this game themselves - and why would they?!)

I'm unsure how to frame that example ("this is THE correct Mastodon profile for THIS Twitter user), which I do think VCs will play a role in.

Outside of a regulated industry, what's the term that will land? Is it verified? Trusted/trustable? Portable? (Likely a blend.)

Thanks for this enlightening read @rileyphughes (and other contributors on that blog post) - definitely very thought-provoking! 🤗 (And sorry for reply-spamming - will post it as a Medium comment too later, but I find conversations are much better on Twitter.)

You can read the unrolled version of this thread here: https://typefully.com/ankurb/u7U5u5C

Thoughts on "Has SSI’s Identity Problem been Solved?"

Privacy-preserving (and digital identity) tech needs to become a lot more like sex education or drug education campaigns. This thought came to me during #RWOT11 @WebOfTrustInfo

A lot of digital identity and privacy is fear-based, on how Bad Things Can Happen With Your Data.

Many people *don’t* care about zero-knowledge proofs or private and secure identity because…it’s complex and boring (for many audiences). So, preaching that people should Really Care About Tracking doesn’t fly because a lot of people *like* ads.

I do myself. Normally I’m armed with 3 different ad/tracking blockers but if I’m buying something expensive, I’ll turn them off and *browse with intent*, hoping to get a targeted add with discounts. Or add something to a shopping cart, hoping to get an email with a coupon.

Preaching to people that they should care about how their data gets shared and tracked and resold is obviously noble, but it’s very similar to preaching abstinence as a measure to prevent STIs, or saying “don’t do drugs” to teenagers.

Instead, a lot of successful campaigns in those spaces acknowledged that people will engage in risky behaviour.

Concertgoers will do drugs…so offer them testing. People will engage in risky sexual behaviour…so offer them condoms or the morning after pill.

People *will* do “risky” things with their data, online personas, and reputation, mainly because our data and identity sharing methods right now are geared in risky, trackable sharing.

How can we offer methods of “privacy harm reduction”, in a way that’s not preachy?

A good example of where privacy tech has been successful is VPNs. They are everywhere: on YouTube, podcasts, online…and while some of it about hiding browsing activity, most VPN players *really* made an impact by offering the ability to watch geoblocked streaming content.

And sure, the other reason is VPNs are an extremely lucrative business with fat margins.

But on both fronts, *people* and *companies* had simple-to-understand value propositions without being too preachy.

It’s why I find the #Web5 pitch compelling as something that gets people outside of the identity conference thought bubble excited. As articulated by @RuffTimo here https://rufftimo.medium.com/web3-web5-ssi-3870c298c7b4

Also by me on the same topic: https://twitter.com/ankurb/status/1535667405539577856?s=46&t=bxNx7P0WlEKPgvaBb8R1ow

I also find @discoxyz’s analogy of a “data backpack 🎒🪩” *also* a good example of explaining the concept in a fun way while still having serious interop and usage for more “serious” use cases.

(I say “serious” and “fun” in the fashion my friends who don’t care about digital identity would)

An example of “harm reduction” privacy tech I can think of is DuckDuckGo’s Email Protection service, that offers randomised email addresses to use online and strips trackers out. See more in our research in Top 5 Trends in Decentralized Identity: https://www.cheqd.io/blog/top-5-trends-in-decentralised-self-sovereign-identity-and-privacy-preserving-technology-in-web-3.0-2022

That’s the food-for-thought I’m mulling over at #RWOT11, among other topics.

When people engage with “risky behaviour” with their data, what are the harm reduction techniques that will make them safer, without necessarily pitching the blanket idea of “more privacy”?

You can read the unrolled version of this thread here: https://typefully.com/ankurb/3XILGGV

Looking at privacy tech through the lens of sex/drugs education

🚨 We built a network-wide validator status monitoring tool for @Cosmos SDK chains that can monitor for validators that have missed too many blocks, and are likely to get jailed.

Check out the code on @cheqd_io's GitHub 👉 https://github.com/cheqd/validator-status

Here's how we went about it...

To provide some context here: proof-of-stake blockchains like @cosmos use a self-reinforcing mechanism to ensure nodes maintain good uptime.

You can see this on our block explorer: https://explorer.cheqd.io/validators

We decided to build this because a few node operators have been jailed in the past for missing too many blocks. As a reminder, validators on Cosmos SDK networks get slashed if they miss too many blocks within a defined window. https://learn.cheqd.io/overview/intro-to-defi-aspects-of-cheqd/how-do-i-choose-which-node-operator-to-delegate-to

On our network, this is counted as “50% of the last 25,920 blocks”: if a validator misses more than this, it gets jailed and 1% of *all* staked tokens delegated to it is slashed/burned.

This works out to:
- 50% of 25,920 = 12,960 blocks
- 12,960 * 6s = approx. 21.6 hours

Most @cosmos monitoring tools are designed for use directly by a validator, i.e., Prometheus. https://github.com/cosmos/awesome#monitoring

This is great for validators who are running this kind of tool (e.g., we use @datadoghq), but it requires validators to run additional infra (many don't).

So we thought of a different way to do it: our BigDipper block explorer (built by the folks @forbole) exposes a GraphQL endpoint that shows validator status for *all* validators. We took this output, wrapped in a Cloudflare Worker (https://github.com/cheqd/validator-status), and voila!

To simplify the task of alerting (and to keep it extensible to other channels), we take the output of our validator status API and parse it via @zapier.

This allows us to send alerts to our @SlackHQ (http://cheqd.link/join-cheqd-slack) and our @discord (http://cheqd.link/discord-github)

Buuuuut...if a *different* @cosmos network wants to set up similar monitoring, or wants to alert to different channels, our setup makes it flexible to achieve this.

Including people being able to set up their own Zapier "zaps" to alert via SMS, email, etc 🤓

You can read the unrolled version of this thread here: https://typefully.com/ankurb/f5ZmyZb

Network-wide validator status monitoring for Cosmos SDK

Many hot-takes in the past 24h of #Consensus2022 have been along the lines of "haha what is #web5 anyway is this a Fibonacci sequence 🫠"

You can hate the game behind buzzword bingo, but THIS is why you should pay attention to @blocks' announcement 🧵👇🏽
https://twitter.com/TBD54566975

"#Web3" is only really decentralised when it comes to financial assets, and even then it can often be limited. Yes, you can theoretically access your crypto/NFT wallet in "any" supported app.

But once you start considering anything more complex than "token", this is hard 😔

Let's take a simple example: if I wanted to take all of my Twitter data, and move it off to a competing social media service, I simply can't do that easily.

(I guess I could dump it onto a 50 GB USB stick, but what good does that do for me? https://twitter.com/elonmusk/status/1534939289653592065)

There are *few* things where I could switch: email, perhaps a file storage service like @Dropbox etc.

But I can't port my viewing history from @Netflix to @disneyplus. I can't switch from @Spotify to @AppleMusic without extremely hacky workarounds https://www.wired.com/story/apple-music-spotify-playlists/

The irony of where we are with the Web is even @TBD54566975's announcement deck...linked to Google Slides (a centrally-hosted service)

(This is not to throw shade at the TBD team, but to highlight how truly broken our relationship with our data is 😕)
https://docs.google.com/presentation/d/1SaHGyY9TjPg4a0VNLCsfchoVG1yU3ffTDsPRcU99H1E/edit#slide=id.g11d24dbeb84_0_0

"I'm happy with Google Slides, why should I care?"

You should care because, at a macro-level timescale, companies will *always* change their minds. Here's only a handful of headlines where users were rug-pulled and their data held hostage 🔫

https://duckduckgo.com/?q=site%3Atheverge.com+%22forcing+users%22&atb=v318-1&ia=web

Every time, Web 2.0 companies turn us into "data refugees" who dance to *their* whims on how long we have access to *our* data:

. List of discontinued services from:

$GOOG: https://en.wikipedia.org/wiki/Category:Discontinued_Google_services
$MSFT: https://en.wikipedia.org/wiki/Category:Discontinued_Microsoft_products
Catch-all list: https://en.wikipedia.org/wiki/Category:Discontinued_software 

Just take where #crypto communities congregate: @Twitter, @Discord, @Telegram, @WhatsApp, @Reddit. We all use @Outlook or @Gmail. We register for events through @Eventbrite. Etc etc etc.

#Web3 is built on the bones of Web 2.0...and worse off for it https://twitter.com/ankurb/status/1534248693456568320

Okay, enough doom-and-gloom: how does "web5", or more generally decentralised identity, save us from this data hellscape? 🤔

The core idea here is that *my* data *can* live somewhere else, I can grant people access to it, etc etc - but *I* should always have a copy.

*This* is why we need decentralised identity, and not just non-transferrable "soul-bound tokens". A vague notion of reputation or "crypto-creditworthiness" isn't enough. We need to make *all* of it portable.
https://twitter.com/BanklessHQ/status/1534569018702831616

"Ah, but #Web5 is just self-sovereign identity by another name, they are stealing our idea 🤬"

Honestly, I've come to realise over the years I've been working in #SSI that "self-sovereign identity" is a *terrible* phrase to explain the concept to a general audience.

It's too "academic". Too often the reaction is "This is boring 🥱, I love my Instagram ads, why is this a problem".

This is partly why all of these "Let's do identity using #NFTs!" projects take off. Because they are *fun*.

Nobody wakes up in the morning excited about #KYC

Which is why I'm excited to see digital identity projects like @discoxyz that are bringing the *fun* back into talking about digital identity, and therefore helping adoption.

We need to move past "zero-knowledge I'm above 18" and KYC 💁🏽‍♂️

https://twitter.com/ankurb/status/1534277685358338050

Far too often, when I'm at #Web3 conferences like @Consensus2022 I hear "ugh, I hate identity, viva la pseudonymity revolución! 🕺🕺🕺🕺"

But guess what? "Identity" is *also* your Twitter handle / NFT avatar / reputation in a DAO / .eth address

https://twitter.com/VitalikButerin/status/1535211774697414660

Which why I'm excited about @TBD54566975's #Web5 pitch: it's sparked an *interest* outside usual decentralised #identity / #selfsovereignidentity circles.

Fine, it might be a tad "Apple FaceID™️ with TrueDepth™️ camera and our best-ever Neural Engine™️", but who cares?

It nearly distinguishes that:

#Web3 is about the democratisation of ownership and governance, with a pinch of financial "LFG to the 🚀!!!"

#Web5 is "but do I *really* have control over my data?"

(It's also a search-engine ranking / SEO masterstroke 🫡)

I also like that the concept looks beyond just cryptographically Verifiable Credentials, since #DIDs / #VCs aren't, on their own, able to shift large volumes of data.

Our thinking @cheqd_io is that Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) are *metadata*, that can be used to manage other off-chain data stores, such as schemas or even large-scale exports (e.g., a Twitter profile) https://blog.cheqd.io/a-new-hope-in-the-data-wars-our-first-ever-non-fungible-did-on-the-cheqd-network-7649cad8cb06

What does this #Web5 vision still lack? At least as far as I understand it, it doesn't address the financial *incentives* for why companies would give users their data.

@brockm @csuwildcat @emilycchiu would love to chat about what we've been building @cheqd_io 👇🏽🙂

You can read the unrolled version of this thread here: https://typefully.com/ankurb/rJ64hpT

Why TBD's vision of "Web5" matters

🚨 Moonshot idea to get DONE by the NEXT @idworkshop... 🚨

Self-sovereign ID credentials should be used as tickets for the #IIW event in November this year 🚀

That's 6 months' time. We spend so much time competing with each other, that we sometimes forget to play nice 🤝

Having #SSI credentials as tickets will compel us, the #IIW community, to dogfood our own software and show that private, secure, "interoperable" credentials work.

We cannot be preaching SSI as "the solution" to everyone else if we cannot make this simple demonstration work.

I also want to *celebrate* the range and variety of different credential formats, exchange formats, wallet/backend software etc that exists. This is good! It offers users a choice!

Yes, this was done once in a past #IIW, ~3-4 years ago. However, SSI technology has massively evolved since then and the industry landscape is vastly different too.

This could even be a recurring thing. Why *not* use IIW as a venue to come together - and test what works!

We don’t need to solve the whole stack of event signup and management: that can still be on Eventbrite (or a similar platform) since it offers payments, email communications etc.

But AFTER registration, the confirmation email/PDF/QR could be turned into #SSI credentials.

This also allows a safety net in having Eventbrite available as a fallback, in case something goes wrong.

Or for people who might not yet know about or be comfortable with self-sovereign / decentralized identity.

If we succeed, we'll have an AMAZING case study of how self-sovereign identity *works* - across a range of different apps/services.

If we don't...well, we learn from it and call a session at the next #IIW to figure out how we make things even better.

Let's do this! 💪🏽

You can read the unrolled version of this thread here: https://typefully.com/ankurb/94t9g7S

Moonshot idea for the next IIW 35

😎 Try out the @cheqd_io demo yourself, get a Verifiable Credential for #IIW 34, and read more about the background for how we built this... https://twitter.com/ankurb/status/1519414834080763909

💡 Our starting principle for this #IIW demo: we wanted to build a non-custodial wallet, which works in a browser.

⚠️ A lot of identity wallets are "custodial" (on browser, mobile, desktop), i.e., they rely on having a 3rd party hold / operate actual credential interactions.

Quite often, this is due to technical requirements on software libraries that can *only* work on specific OSes.

Example: Many Aries frameworks rely on software libraries that are specifically compiled for iOS/Android/Linux/Windows/Mac. 😔

(Not a fan of Twitter 🧵s? Read everything below in a Google Doc at: https://docs.google.com/document/d/1NDPUG_8oVzh8KcUI507LDW41yceRqSWEJb5vbK9Zjkc/edit?usp=sharing) 

👩‍💻 Try out the demo yourself! (steps for Chrome desktop)

Pre-requisites: First, you need a @keplrwallet browser plugin (if you don't already have it) from keplr.app

...and add the chain config for @cheqd_io via cheqd.omniflix.co

Keplr is a common browser wallet - like MetaMask -  for the @Cosmos ecosystem. It is used in our demo as an alternative to username/password authentication but is NOT widely mandatory for our network. We wanted to show how a web app wallet could interact 3rd party wallets.


Go to wallet.cheqd.io and connect using Keplr extension. This will prompt for read-only access for your cheqd wallet address - and acts as a form of "account" on the website.


Time to create your identity wallet! Click the "Identity" tab on top, and then "Unlock": which either restores an existing wallet or creates a new one.

We do this by authenticating that you can sign a message using Keplr wallet, as a zero/no fee interaction.


Once authenticated with Keplr wallet, you'll be prompted for a passphrase for your identity wallet secret box. This passphrase is used to lock/unlock the "safe" backup/storage for your credentials.


Now, time to get your #IIW 34 credential! Click the "Get" credential button, which will generate a unique credential, with an issuer DID anchored on @cheqd_io mainnet (did:cheqd) - and issued to a unique, off-ledger DID (did:key) for the credential subject.


The did:key identifier is generated in this example as a derived public key from the wallet address, but could theoretically be derived in *any* other ways as well.

We also developed a @DecentralizedID Universal Resolver that can be run into two formats: a "full" resolver that pulls authenticated from a node, or a "light" resolver that can query the gRPC/RPC endpoint for an external 3rd party node.

Example: https://resolver.cheqd.net/1.0/identifiers/did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1JXfUY7oVWkY

If you click the "Lock" button, this securely backs up the credentials you have to a @Cloudflare database (actually, a miniflare.dev instance) - but *only* in an encrypted format which ensures neither @Cloudflare nor @cheqd_io can see the contents of the box.


Under the hood, we're doing something *very* similar to how password managers such as @LastPass or @1Password work: only an encrypted copy of credentials is backed up. When you connect via Keplr, the backup is downloaded and decrypted *only* within your browser.


Phew! That was a lot! 😮‍💨

So what does this show? it shows a non-custodial wallet, that can be recovered. *Only* the end-user, and whom they share it with, can see the contents.

Obviously, this is only an example! An app developer could do a custodial wallet instead.

Or, instead of using a Cosmos/Keplr wallet to authenticate an account, an app developer could use any other mechanism, such as username/password, SSO/OAuth etc.

🤓 To implement the credential issuance, we built this on top of veramo.io's SDK, since we found it was *highly* modular. This is a *very* rough sketch, but it explains the concepts involved in abstracting modules for DIDs, VCs etc - almost as an "SDK-of-SDKs"


The current demo only shows the issuance flow, using JSON-LD credentials with did:cheqd.

We want to expand this to allow, for instance, to have "AnonCreds-like" credentials, anchored on did:cheqd as an alternative to did:indy

An SDK-of-SDKs...or a modular SDK enables this.

Our original approach/attempt, before using Veramo, was to try and decouple the native OS dependencies from Aries Framework JavaScript (https://github.com/hyperledger/aries-framework-javascript) or Aries Framework Go (https://github.com/hyperledger/aries-framework-go) into Web Assembly (WASM).


WASM would allow us to run the libraries in browser, or on serverless platforms such as @Cloudflare Workers workers.cloudflare.com

Why? If we could get the entire library/SDK working in a browser, it can *always* be repackaged to work on mobile/desktop OSes.


We ran into two challenges with this:

Many Aries Framework libraries rely on *really* old versions of Node.js (v12.x) which are end-of-life (the latest LTS version is 16.x). This meant rebuilding was hard in general, and a lot of old/vulnerable libraries.

This, on its own, is something we should rally around among #IIW attendees / #SSI community and beyond, to patch and maintain @Hyperledger Aries better. We're having conversations regarding this with open source contributors.

There's a real "someone in Nebraska problem" here

Aries Frameworks aren't *currently* designed to be ledger-agnostic, or modular enough to easily add support for new DID methods. These tight dependencies make it hard to extend and incorporate new functionality.

We know there's a LOT more to do, but we hope this gives just *some* idea of what we're doing @cheqd_io on wallets and SDKs that can be used by #SSI / app developers.

If you've made it this far or seen the demo @idworkshop, come holla at us 👋

You can read the unrolled version of this thread here: https://typefully.com/ankurb/PDcaiMP

Summary of cheqd's identity wallet demo at #IIW

It's been a HUGE quarter for the @cheqd team: We’ve upgraded our network’s identity features, bridged to Ethereum, plus much more… 🚀

https://blog.cheqd.io/q1-round-up-from-cheqd-weve-upgraded-our-network-s-identity-features-bridged-to-ethereum-and-4012aacfc5b6

🤓 We published a meta-analysis of the size of the self-sovereign identity industry which got picked up by @business and @thefintechtimes https://www.cheqd.io/press/cheqd-meta-analysis-finds-the-self-sovereign-identity-market-is-worth-over-550-billion 

We also published a survey of general and expert audiences on the Top 5 trends in #decentralised digital identity and Web 3.0. 

Read more: https://blog.cheqd.io/top-5-trends-in-decentralized-self-sovereign-identity-and-privacy-preserving-technology-in-web-3-0-b677926bcfc7

We've been a bit slower on the identity news as we spent the past couple of months doing *major* refactors to allow our network to accommodate the latest in @W3C Decentralized Identifiers, to offer a compelling and scalable alternative to @Hyperledger Indy.

We also wanted to work on the educational piece of helping people understand what #selfsovereignidentity is at learn.cheqd.io 

In this quarter, we're looking at:

🔍 Universal DID Resolver that makes the developer experience of integrating cheqd much easier

🗃 A web-based wallet for $CHEQ tokens… and credentials: we want to show technical implementations of how the new identity functionality and #DeFi functionality on our network can be used, almost as a blueprint for other SSI vendors. (Yes, we will be open-sourcing our code.)

🙌 We grew from 6,000 active wallets in early 2022 to over 73,000+ active wallets. This is very rapid traction, down in large part to the partnerships with major app developers we've formed, and our efforts in community-building.

🪙 Launched an ERC20 version of the $CHEQ token, thanks to our partners @AltheaNetwork and their @gravity_bridge.

Which means...we're also now on @Uniswap 🦄, in addition to our existing DEX listings on @osmosiszone 🧪 and @emerisHQ 💫

Being able to support price-stable mechanisms of payment for identity exchange is crucial for @cheqd_io, and this gives us the ability to start laying down the foundations for #stablecoin payments within the @cosmoshub ecosystem as well as integrate with #USDC/#USDT


💹 We also listed on @BitMartExchange, a premier centralised exchange with 9mn+ users, as well as a strategic partnership with   @Indacoin, which allows more people to participate in our ecosystem.

We heard a lot of people loud and clear that wanted to participate in our ecosystem, but decentralised apps/exchanges were hard for them to understand - and this makes that process significantly simpler.

✅ Our upgraded cheqd mainnet brings new decentralised identity functionality, which we'll be publishing tutorials for app developers very soon.

We also welcomed many, many more SSI partners onto our network: @AnimoSolutions, @myCredential - as well as large #Cosmos partners such as @forbole, @CitadelDAO, @lavender_five, @everstake_pool, @WhisperNode, @blockfend, @nodes_smart, @EZStaking, @EnigmaValidator

Stay tuned for more as we build towards the new decentralised digital identity functionality we want to offer on our network - and simpler experiences to deal with the challenges of how to deal with our data in a privacy-preserving manner... 💪

You can read the unrolled version of this thread here: https://typefully.com/ankurb/fkJ5a8L