You may be interested in this. It’s a lite version of solid, for an easy developer experience.
It is extensible in different ways, all the way up to Big Solid, to be AP compatible, to be compatible with microfed and nostr etc.
It will have built in nomadic identity as first class
Just FYI, the JSON example has an error (no colon after primaryTopic). For AP bridging, would it be consistent with a WebID document to add the activitystreams context and a top-level actor property that refers to the AP actor resource?
Also, publickey doesn’t appear to be defined in the context (removed in the following example).
{
"@context": [
"https://www.w3.org/ns/activitystreams",
"http://w3id.org/webid"
],
"primaryTopic": {
"@id": "#me",
"@type": "Person",
"name": "Will Smith",
"img": "avatar.png",
"knows": "http://alice.example/#me"
},
"actor": "actor/me"
}
Thanks so much! Fixed here.
I could indeed add the activitystreams vocab. At this point in time it doesnt do any harm. But there are some slight nuances around it.
Publickey is not defined but I think it will just be 64 char lower case hex.
The system is taken from the WIP for SolidOS. They are also using pubkey and it’s not in the vocab.
I could put publickey in the webid vocab. Though if I add the activitypub vocab, then it would get expanded to a bnode. I think it’s not a dealbreaker at this point.
I have written a basic server and it works great already. I’m just going to do the auth and we should be good. This can also be a basis for microfed profiles. I’d need to add inbox, outbox, followers etc. too.
rather than “actor”: “actor/me”, better is to have two things in the @type, the Person and the as Actor. We could shove this in the webid context
Linked data allows multiple types of course.
Yes, I experimented with that approach too. Using two @type values is fine, but I wasn’t sure how to handle the two @id values (assuming the WebId @id is different from the AP actor @id). I was also thinking it might be useful to keep the WebID/foaf data separate from the AP data in the profile document.
I noticed today that BlueSky’s (bsky.app) DID document has a publicKeyMultibase that’s not defined in the @context. Maybe that’s some kind of security technique? It seems like it would break JSON-LD processing since the property will be dropped during expansion.
You are not allowed to have two @id in an object, only one per object, it’s quite fundamental.
A WebID and an AP Actor were designed to be the same thing. So that is again one @id. They could have been even more closely tied and interchangeable, we wanted that in the WG, but we didnt get it over the line.
I think the profile should be a mix of both data, the user can choose, or will be able to in microfed. Ought not break anything.
The DID approach is completely wrong, at this point id consider it harmful. Bluesky makes it even worse by add their own protocol (like a new DNS) on top of both that DNS. Credit to them they have a great system with a great server and great UI. The spec has a lot to be desired and will ultimately always be controlled by Bluesky Inc. nothing will ever get in there that they dont want. Dont use multibase either, IETF have labeled it harmful, and I agree. They ultimately just want to sell their tokens IMHO.
Regarding breaking JSON-LD, yes indeed, but they dont seem to care any more. The working group can just override anything or any objections. They’re probably about about 5 flavours of JSON-LD now. We may need a lite version! Solid-lite take @id (singular), @type (array) and @context. I’m curious to see if I ccan build a full inbox and outbox and if i hit any walls. A followers collection ought not be that hard to do. I also wonder about followers from across the whole internet (e.g. both solid-lite and activitypub), just denoted by a URI.
Yes, that’s what I was saying. It wasn’t clear to me if a dereferenced WebID document was the same thing as an AP actor. If they are, then it’s not an issue.
To be AP-compatible, the @id and @type will need to be at the top level of the JSON-LD document rather than in the primaryTopic, right?. I didn’t see any @id at the document top-level, so I thought that must be a blank node (which wouldn’t be AP-compatible). That’s why I added the actor property to point to the AP actor URI.
(You may be refactoring this, and if so, just ignore my comments for now.)
Thanks, this is really valuable feedback.
Both docs were designed to be the same and interoperable, allowing slightly different approaches to work together.
primaryTopic is the solid way at top level, just how AP has publicKey in a nested way
There could be some compromise on this, but it’s largely the same. Worst case scenario is that a temporary bridge will be needed, but you’d hope that it was not needed.
I’ve added Actor, followers, following, inbox, outbox which should increase capability alot.
I think this goes a long way to making unified Solid and AP profiles, and I’ll have a look at inbox and outbox, and see if i can implement it in microfed.
We’re getting closer!
This isn’t completely clear to me, but I’ll see how it evolves. There are a few technical issues with the latest update. If you prefer, I can create GitHub issues going forward.
The activitystreams @context entry must be first because the WebID context is protected and there are overlapping terms. (There’s a missing comma in the @context too. I’m catching these issues by entering the example document into JSON-LD Playground.)
I’m assuming the Actor type is supposed to be the AP Actor (?). However, there is no Actor term in the AP/AS context. To use AS Person you’d need to specify it as as:Person because of the clash with foaf:Person.
Using as:Person is technically compliant since it’s the result of compacting the document with the normative context (combined with the WebID addition). However, it’s very unlikely to be interoperable with any AP implementation doing simple JSON processing (almost all of them), even if they support multiple types.
(If the AP implementation does support multiple types, it might work in a hacky way. A plain JSON-based app is typically going to consider the “Person” type value as the AP type and ignore the “as:Person” because it doesn’t know what it is.)
This is why I originally suggested adding the AS actor property to the WebID profile and keeping the AP actor documents (and ids/URLs) separate. That way, AP “clients” can dereference the actor and get what they expect and WebID will work as expected too while still linking to the AP resource. It also makes it relatively easy to incrementally add WebID support to an existing AP implementation (compared to a merged document).
This is great feedback, I will fix all these points. If you are able to raise a github issue it would be much appreaciated. If not, I will get round to it, for sure.
I can put the AP context first, but the protectedness is a point of centralization, for the future.
Actor = AP Actor yes, I can namespace that. The webid context id need to check with the other person that looks after that first, so I was just getting some stuff in there quickly. re: Person I ought to check what the latest solid does, there’s also vcard : Person too. Context is supposed to be a helper, not a restriction really.
I can try this out in microfed, perhaps an idea could be to do a quick transform on the inbox and outbox micro services. I guess if other servers are checking the profile it’s going to be a problem. This is probably something more difficult to compromise on, because I want good profiles. We’ll have to figure that out.
Some tricky things here, perhaps it’s possible to do a hack of content negotiation for backwards compatibility. My JSON is going to go in HTML anyway, so i dont care much what goes back to activitypub requests. All good points, thanks alot, Ill go through them in detail and figure out fixes or workarounds.
I think could make a stab at microfed with this.
Does that mean existing Solid implementations could easily be rejiggered to only provide solid-lite?
I’d love to hear you expand on that! Does it rely on a piece of nostr as a core dependency? The fundamental differences to Bluesky’s approach would be enlightening.
Could solid-lite support some equivalent of Solid-OIDC? Support for Solid-OIDC and WebID was added in the latest release of Rauthy, so perhaps that sets the stage for easy solid-lite support as well 
Does that mean existing Solid implementations could easily be rejiggered to only provide solid-lite?
Yes, should be quite easy. Just set an ACL to say everyone can read, owner can write at the root.
Auth will be a case of level 1/2/3. 1 (null auth) supported out of the box – do nothing. 2 API_KEY is an easy add for personal online data store. 3. PKI Auth for multi user servers is a bit of work but not much. Maybe a day. That would be baseline support in different scenarios.
I’d love to hear you expand on that! Does it rely on a piece of nostr as a core dependency?
The approach to PKI taken by SolidOS is to use schnorr signatures. Meaning your 64 char hex key is tied to your profile ID. An identity could be provided at the well-known path by dropping in a file. Reverse lookup by webfinger, or by providing a relay to lookup your profile from a key, quite easy. Nostr integration will be quite easy because it requires nothing more than a keypair and you can do everything, so adding one field to the profile in its simplest sense. Migration in nostr is no work, it’s native, so you get that for free.
The profile is the basis of tying everything together. Storage, followers, social graph, pubkey, inbox, outbox. Soapbox and ditto are quite advanced in this. The WebID community group are also making a JSON-LD version which makes life easier.
What we’re talking about is tweaks here and there, not a huge amount of work, just reuse the existing infrastructure like a bridge, but more native than a bridge.
Bluesky could work but that would be another module added to solid lite (SLIP) to interact with their model. However, fundamentally RPC is not the web, and bluesky identity is messy.
Solid Lite will have to support Solid-OIDC. It’s quite a beast though, and quite buggy, so it will be alot of work to get right. One of the motivations for Solid-Lite was to reduce that complexity. Congrats on implementing it, was it hard to debug? Solid-Lite could certainly copy or support Rauthy.
The aim was to build a useful working server in a weekend and get up and running with apps. It’s already proven to be able to do that.
Next phase will be SLIPs to add the functionality that everyone wants, Range 3001-4000 SLIPs are set aside for AP integration. My guess is that with about 5-6 modules you’ll get basic interop going. And I’ll build that into microfed which will be Solid-Lite + AP.
