JG10

@jg10
72 Followers
60 Following
265 Posts
Interested in #SolidProject and enabling user control over both their data and the interfaces used to interact with it (#MalleableSoftware), especially with #PodOS
Past devlog noteshttps://jg10.solidcommunity.net/devlog/home.html
Github code mirrorhttps://github.com/jg10-mastodon-social
Nowhttps://jg10.solidcommunity.net/devlog/home.html#now
Bridged on BlueSkyhttps://bsky.app/profile/jg10.solidcommunity.net
I've been experimenting with #SolidProject agents and I like the elegance of https://github.com/solidcouch/solid-identity - the agent hosts its own webid and issuer - no login required, instead the user just grants access to the agent webid
GitHub - solidcouch/solid-identity: Simple solid identity for REST services - monorepo

Simple solid identity for REST services - monorepo - solidcouch/solid-identity

GitHub

There’s a tension between being semantically rich (using your own terms and definitions), and being semantically aligned, in which you try to reuse terms from other vocabularies.

I think we need a new concept: eventual #interoperability. I propose to start rich with your own vocabularies, and only make alignments when there’s a concrete reason for building those.

https://pietercolpaert.be/interoperability/2026/01/08/eventual-interoperability

#knowledgegraphs #apis #linkeddata #semantics

@richard If you're referring to the default interface (SolidOS), you're right, though there's currently an NLNet funded project to advance it. There's a fair bit of other activity including business-to-business endeavours. The protocol itself is now being revised by a W3C working group: https://www.w3.org/groups/wg/lws/
Linked Web Storage Working Group

The mission of the Linked Web Storage Working Group is to enable the development of web applications where data storage, entity authentication, access control, and application provider are all loosely coupled, as opposed to the web of today where these are typically all tightly coupled and changing one requires changing all, sometimes at the price of all past data. This will be achieved by identifying a set of relevant <a href="https://github.com/w3c/lws-ucs">use-cases</a>, and standardizing a <a href="https://github.com/w3c/lws-protocol">protocol</a> between applications, on the one hand, and identity and storage servers, on the other hand.

W3C

Learning about #WebSub as a way of getting push notifications instead of polling feeds, including for YouTube videos

https://www.w3.org/TR/social-web-protocols/#subscribing-hub

https://developers.google.com/youtube/v3/guides/push_notifications

Social Web Protocols

My experimental #SolidProject webhook config now also has an indexer that adds new schema:Action tasks compatible with https://focus.noeldemartin.com to an ItemList

Works well with additions to a container, but listening to edits would require subscribing to updates from individual documents.

I'm still regenerating the index daily as well and currently thinking of it as an index that provides eventual consistency. The consumer should assume updates and deletions/tombstones may be missing.

Focus

Your distraction-free Task Manager

Did you know you can use your #Solid Pod to store a Digital Twin of your coffee machine?

The latest #PodOS release makes it easy to attach classic documents to your things, like a PDF manual, warrenty document or invoice.

We also bring more life to the dashboards, showing things from your type index.

https://pod-os.org/blog/2025/12/22/podos-202512-brings-attachments-and-discovery/

PodOS 2025.12 brings attachments and discovery - PodOS

My experimental agent now successfully loads the inboxes and outboxes to listen to from config for two different actors.

Private keys are managed by the agent.

I did run into the problem that apparently Mastodon checks webfinger for a follow request

My experimental #ActivityPub #SolidProject agent now listens to POSTs to a list of inboxes and outboxes and processes activities asynchronously as they arrive.

Next I plan to dynamically define the inboxes and outboxes.

The agent would be given access to a config, subscribe to the listed topics and connect them to the appropriate handler.
It would also set the public key on the named actor. e.g.

:myactor_inbox a :WebHookRegistration;
:topic </inbox/>;
:handler :InboxModified;
:actor </actor>.

eye import.n3 --query query.n3 --wcache https://pod/movies ~/movies

import.n3:

{
?scope :imports ?file.
?file log:semantics ?s
} => ?s.

[] :imports <container.ttl>. {
? container ldp:contains ?movieDoc. } => {
[] :imports ?movieDoc. }.

I've proposed two possible outlines for a document about #SolidProject #Activitypub integration

https://github.com/solid-contrib/activitypub-interop/issues/2#issuecomment-3590595603

The first is more note/tutorial/primer like, because a large part of the content is just redescribing ActivityPub for a Solid audience.

The second assumes prior knowledge of ActivityPub and primarily describes what is needed to integrate ActivityPub with Solid, based on three architectures:

- Server support
- External processing
- External endpoints

Is this specification for Pod providers or for agents ? · Issue #2 · solid-contrib/activitypub-interop

I believe the wording in the specification will be different if the objective is to help a Pod provider implement ActivityPub, or if it is to help develop an ActivityPub agent. At the moment, we do...

GitHub