2024-49 dev log

[michielbdejong]

This week I plan to work 8 + 7 + 6 + 0 + 0 = 21 hours, most of it on hopefully wrapping up the Solid Slack Bridge milestone for SDM.

[michielbdejong]

First two hours of today spent researching solid/specification#699.

Good to see rigorous discussion about the metadata discovery mechanism, and the Solid project offers room to experiment and report back.

But to make this mechanism usable we will need to implement it in multiple servers and in multiple apps. As Kjetil commented, "a fundamental discovery mechanism like this MUST be MUST".

So the upshot is we'll still need to document this as a community-level requirement before we can use it in any way. But we can start with shipping it in Pivot and maybe TrinPod, and use it in Solid Data Modules, and then work on the documentation as a community in 2025.

[michielbdejong]

I asked Fred if he could add a storage capabilities description to TrinPod in https://matrix.to/#/!QxZtVBYQfMeMTnespj:gitter.im/$q5ak_CloJlLiL79D4PPQpk3_jsAL4a0kt8714c8uJwg?via=gitter.im&via=matrix.org&via=chat.semantic.works

[csarven]

nodeSolidServer/node-solid-server#1802 (comment)

[michielbdejong]

Next issue: the IdentityManager from tubsproject/reflector#16 doesn't have a good way to interact with getExpressRoutes from solid-client.

I'm not sure whether I want to force all data home clients to expose their GUI as express routes, although for now it's workable if I stick to one subfolder per data home client.

The Solid client has its own state, including its own session state. It gets a postgres client to store that. But it should also be allowed to set the current session in the IdentityManager. So should I pass it an IdentityManager in the constructor? Or use a callback via the main index.ts? Maybe emit an event?

[michielbdejong]

The state change events would for now be adding/removing identities. Then when creating data sets, there will be sync events. So EventEmitter feels like a good path there, probably.

[michielbdejong]

tubsproject/reflector#16 (comment)
Maybe I should spend some more time to get this right. Maybe just write a version of Reflector that only handles login and logout, and no actual functionality.
Another concern is I need to publish the TUBS app to the Slack marketplace.
I need to juggle this between the short-term need to finish the NLnet milestone for SDM now, and the long-term need to set a firm basis for the TUBS project. So I should select what I'll do this week and what can be left for later.

[michielbdejong]

Next: use IdentityManager instead of SessionStore in SlackClient onMessage.

[michielbdejong]

Hm, but when src/utils.ts calls getSolidDataset and saveSolidDataSet, it still uses session.fetch from the @inrupt/solid-client-authn-node session that was stored in the SessionStore. Will need to get that from @tubsproject/solid.

[michielbdejong]

Hm, and apparently this Solid Session is just JSON-stringified into the database.

[michielbdejong]

Ah right, that code didn't even have a database, which was why it could keep all sessions in memory, and use them in a background process.
But JSON stringifying to db doesn't work because of circular references. There must be a way to use @inrupt/solid-client-authn-node with a db backend otherwise you could never give a bot access to your pod. I'll dive into the docs some more.

[michielbdejong]

Hm, https://docs.inrupt.com/developer-tools/javascript/client-libraries/tutorial/authenticate-nodejs-script/ looks quite complicated, it seems to have two options (refresh tokens or static client credentials) and only the second one is supported.
And then still, this wouldn't help me interact with NSS from a bot. I'll try instead if I can serialize the express session without running into circular references.

[michielbdejong]

Ah, or even just session.info.sessionId

[michielbdejong]

Next: tubsproject/reflector#18

[michielbdejong]

That's fixed, and Slack->Solid works, so it's more or less ready to demo now.
I'll probably plan to wrap up this milestone tomorrow.
Will think about what I can add in these last two days to make it nicer.

[michielbdejong]

OK, I thought about it. :) There are a lot of things I could work on next, including:

• launcher app
• GUI, code quality and proper CI setup for Reflector
• two-way sync

But I think the next most urgent thing for me to wrap up is now is Pivot and the NSS->CSS migration.

[michielbdejong]

For pivot launch I'll look into an LDP handler that catches 404, 401 and 403 for content-type html, and rewrites it to a redirect, see solid-contrib/pivot#4 (comment)

[michielbdejong]

Reading https://stroudcommons.org/introducing-commons-ideas-at-the-festival-of-commoning/ makes me excited about credit commons as a topic to work on (rather than data portability). Both topics can co-exist within TUBS project, of course.

[michielbdejong]

The name 'The Ultimate Bookkeeping System (TUBS)' has 'bookkeeping' in it, so the 'ultimate' can point both to data portability and to a more peer-to-peer form of accounting.

[michielbdejong]

There is still a lot of code quality to be done to get this code from hackathon quality to MVP quality.
For instance tubsproject/reflector#22.
I need to make a decision about that, and weigh the "R&D" balance between Developing good code vs. doing more cutting-edge Research.

effect = quality * acceptance.

[michielbdejong]

Two weeks ago I made a list of goals for Solid-Slack-Bridge. Maybe I should just do a quick dip into Pivot work today, and then go back to evolving the Reflector code to something presentable.