National skies vaporware backed by verifiable credentials

Share your project
1

So, I’m going to start off humbly by saying my project is vaporware at this point, but I’ve presented it for @erlend.sh and others, who thought I should share it more widely, and I’ll also be at Eurosky Live, so here goes…:

Basically, my project is public interest social media as infrastructure for deliberative democracy. I’ve had a bit of work talking about it, a recent thing was some very cross-disciplinary workshops as side-events to the Internet Governance Forum 2025, that I co-organized as a consultant for the Digital Public Goods Alliance.

My own background is in the Semantic Web area, I’ve been involved with that since 1998, and eventually did my ph.d. in the area. I was also co-editor of the Solid Protocol spec. I felt Solid was kind of a last-ditch effort to make semweb useful, and when it failed to do so, it was time to start over. People have been saying good things about atproto, so here we go. I can help pillage Solid for parts though.

We’ve got parts of the Norwegian government interested in atproto as basis for public interest social media, and so, I have written a proposal for a near-term roadmap, which is making its way around, whether it ends up funded by a foundation of some sort, some governmental agency or not at all remains to be seen, but the roadmap has a workstream that has the following deliverables:

  1. A component that generate an atproto Label based on a W3C-standardized Verifiable Credential.
  2. A system that generates Verifiable Credentials to certify that a decentralized identity (DID) holder is for example a Norwegian citizen, or a qualified voter, etc.
  3. A product that feels like a Norwegian section of a social media by using the labels generated through the first two, but is still an unmistakeable part of the greater ATmosphere.

Funding is not the only thing that could make it hard to do. Another thing is that The Norwegian Digitalization Agency has set up a sandbox for verifiable credentials, and vowed to populate it with real data RSN. If the project was accepted into the sandbox, the second deliverable would be easy, but it is very uncertain if it will.

For now, I’m reading the specs with interest, I’m excited to meet people in Berlin, and to share how it goes.

3 Likes
2

Welcome Kjetil!

So what’s needed is a labeler based on Verifiable Credentials, and one specific use case for this (which there is some potential funding for in Norway) is a proof-of-nationality that’s safely decoupled from the platform providers.

This is very useful for the local atproto.[locality] communities that are popping up, like atproto.boston, atproto.no (as of yesterday) etc., as it enables verification of a cohort of users that could eventually get to participate in the co-governance of that local group, a special privilege that should be reserved for actual locals.

VCs can support more than one way to authenticate oneself as a local, ranging from state IDs to peer-based groups like a data/hackers collective.

1 Like
3

Hi from the Solid Community! This sounds like an interesting project, and provided funding I could almost certainly build it. Could also solve some problems with age verification laws.

I would probably also suggest writing a record to the PDS that links the verifiable credential / verifiable presentation to the account, besides just adding labels (whuch aren’t really for this and would allow people to hide all Norwegian people using this (probably undesirable)

It’d mostly be just a bridge to connect PDS Account & VC/VP via AT Protocol OAuth and the wallet connect flow.

Thing to be mindful of: selective disclosure, signatures & encryption.

2 Likes
4

Great to hear from you @thisismissem.social ! One problem, if we get any of this running, is that the actual auth flow is very expensive for the government, they basically outsourced it to banks that can charge any amount of money for the usage, so we’d have to be mindful that usage of the actual identity is something that can only be done seldomly, which is also a reason why the labelling idea came up (via @robin.berjon.com ).

It also needs quite a lot of work on pseudonymity and that kind of stuff, so yeah, selective disclosure is a big topic, but one that isn’t on my roadmap for the next few months.

Anyway, I’m very open to the details here!

1 Like
5

Welcome! Thanks for sharing the idea!

Not sure that labellers are the right tool for this, including that the labeler owner is in control of the label not the user themselves.

If the end goal is feeds, then a custom coded feed or seeing if Graze can meet your needs would be good.

Storing it as a user record that the user opts in to might be the most likely path.

Making it work with the Bluesky client apps initially (feeds / labels / lists / whatever) would be a start for prototyping, but I’d consider eg forking the bsky app or otherwise thinking about “what does Norway social media want?”

6

Not sure that labellers are the right tool for this, including that the labeler owner is in control of the label not the user themselves.

Yeah, but I don’t think that’s actually a bad thing. The label would be requested by its user, but the labeller could negate it if the user changes citizenship, had provided fraudulent credentials, etc.

If the end goal is feeds, then a custom coded feed

I’m thinking about it in generic terms. I think for an MVP, just a feed would be great, but it should be more generic infrastructure with uses I cannot yet envision.

or seeing if Graze can meet your needs would be good.

I have to look more into Graze! I haven’t gotten very deep into it yet.

Storing it as a user record that the user opts in to might be the most likely path.

OK, I’ll look into that too!

I would love to discuss this further on Eurosky Live, BTW! I put a statement on the pre-meeting Polis to that effect :slight_smile:

Making it work with the Bluesky client apps initially (feeds / labels / lists / whatever) would be a start for prototyping, but I’d consider eg forking the bsky app or otherwise thinking about “what does Norway social media want?”

Yeah, so long term, what I’d like to achieve is that what Norway wants is not up to me, but up to our democratically elected representatives who interact with someone like me :slight_smile: So, this is more an effort to get into the position where such representatives start believing that a different kind of social media is possible to create.

If we did make a label, then BlueSky could use it right out of the box, right? And we could put up a national relay that used those labels?

1 Like
7

Yes labelers will work in the Bluesky client apps today.

Relays are pretty irrelevant here. You can run one if you like (costs about $30/month) but eg having a PDS for sovereign account data hosting is higher priority (and if you vet / invite people to this hosting, that’s yet another way to verify Norwegian users, although I would still verify people who don’t choose to use the hosting or self host etc)

There’s lots of nuances to the ATProto architecture because it’s so modular! Happy to chat over the next several days.

8

Whilst you could try to do a PDS where account creation is gated by identity verification, anecdata suggests that majority of people don’t want their idea associated with their social media usage (even if they believe others’ should have their identity associated with their social media usage)

1 Like
9

So, I have some good news! I managed to get a bit of funding, so I will start looking into coding again. I’m just going to be exploring various ways to do it, including putting the credential on the PDS, looking into the verified checkmark (BTW, I haven’t found atproto docs on that, just Bluesky docs) and label. And combinations thereof.

1 Like
10

The verified checkmark is a Bluesky lexicon. It’s “just” a lexicon.

You could adopt the Bluesky lexicon, and run custom feeds or run a forked front end that lets you pick verifiers, like deer.social does.

You could make no.example.verification on your own - and then build custom feeds of “verified Norwegians”.

A “record” always has the “credential on the PDS”.

2 Likes
11

If you did want to become a “bluesky verification service”, then you need to work with them to approve you, and then you’re just writing app.bsky.graph.verification records, here’s the schema.

2 Likes