Community agency and metatools insertion strategies

Ideas
1

Hi all,

Long time without posting (this place is so fascinating that I need to restrain myself to enter or I’ll be here for hours). Anyway, here is my new post that presents my new path to explore malleability in the context of my teaching/research experiences at HackBo, our local hackerspace at the information sciences department at the university, and how this new approach is complementary to the one I have had with Pharo/GToolkit while creating Grafoscopio. This time I’ll be using Lua to build and co-evolve an wiki engine as a Hypermedia System.

I think that it shows another approach/genealogy for Convivial Computing and highlights the importance of community and context in an action research bet for malleable systems in grassroots communities with enduring relationships in comparison with the more theoretical/computational emphasis of the research on malleability in the Global North.

Here it is:

Community agency and metatools insertion strategies

As usual, feedback, in this very thread is welcomed.

1 Like
Smooth Gradients of Composability, or Old Man Yells At Compilers
On UI as Code
On UI as Code
2

I like the idea of taking up the TiddlyWiki concept and improving on it! But you discussion of Lua suggests that your Wiki engine will be server-based, as opposed to a TiddlyWiki which is a document independent of any server. Did I get that right?

3

Thanks @khinsen for engaging in conversation as usual and yes, you did get it right.

Our experience has shown that if you want TiddlyWiki data to become a fluent part of an knowledge ecosystem, you will need to address the server part, sooner or later. And I said that after developing and mantainning tools like TiddlyWikiPharo, that allowed us to avoid systematically the server part all this years, after my re-immersion in TiddlyWiki, since 2020.

I will provide more context, first talking about we have accomplished without a server and then why we need take care of the server part and how I plan to avoid the incidental complexity, despite of adding a server.

Thanks to TiddlyWikiPharo, we have been able to use a DSL in a general computer language (Pharo) in:

In all those projects/prototypes I was able to enjoying live coding the data from Pharo and molding it back and forth between external sources and TiddlyWiki. The combination of TiddlyWiki, Pharo and Fossil created a agile “minimal”[1] stack using the first one as a content and interaction web delivering platform the second one as a data processing and visualization platform and the third one for collaboration, persistence and publishing.

But the formal and informal conversations/surveys showcased that our community was using mainly HedgeDoc and TiddlyWiki and minimally Grafoscopio/Pharo/GToolkit. Despite of the power of such stack (where Grafoscopio connects most of our external tools) and the relative fluency connecting the parts of it, the malleable experience was confined for most people to TiddlyWiki and only if they use features like macros, filters and operators, what happened minimally also (or was not shared/published at all, except for a couple of members).

The fact is that the browser is already there and that HedgeDoc and TiddlyWiki were addressing pressing needs regarding community/(inter)personal memory for less/sync structured and highly/async structured documents, respectively. Connecting everything with Grafoscopio/Pharo created a level of friction (downloading the Pharo/GToolkit desktop app, enriching it with Grafoscopio packages, running the data narratives that explain/connect other systems data) the that most people would not traverse, keeping malleability experience even more limited. And inside TiddlyWiki, the most malleable web tool of the one we used, there were still the problems of TiddlyWiki’s domain-specific languages (DSL). All this called for a more structural approach.

As I said in link provided in the original post:

While previously I thought in Fengari as my way to implement embeddability to increse agency in the (web) tools, the recent developments on hypermedia systems make me think that I can keep avoiding JavaScript[2] and implement the strategy server side by reimagining TiddlyWiki in Lua+YueScript. Cardumem is the working name for such idea, and as explained in that link the intend is to provide a similar gentle learning curve between being a content creator and a functionality creator, that TiddlyWiki give us, while being able to generalize the concepts learnt while using and extending the wiki in its own functional DSL to other computing languages
[…]
regarding the “Not Invented Here syndrome”, the differences with TiddlyWiki are enough to justify why we need to invest all that work in Cardumem, as community and (inter)personal knowledge management is a core concern5 in the Grafoscopio community, to the point that we need to reinvent the wheel, for the contexts where the already existing ones don’t work as we expect for our needs.

So, this time, I’m extending a wiki engine from a DSL made in a general computer language (YueScript) that runs in the wiki engine, instead of the DSL that runs outside, as I did previously with Pharo.

Regarding adding a server, from the Cardumem source code repository:

Lua and YueScript would resonate with the simplicity that exists in TiddlyWiki and while a web server is added, to create a Multi-Page Application (or MPA) instead of the Single Page Application (or SPA), it is expected to maintain much of the cross-platform portability, thanks to the high embeddability of Lua/YueScript and the simplicity of hypermedia systems, compared to their JavaScript counterparts. The table as a single data structure in Lua and functions as first class citizens, would preserve the uniqueness of Tiddlers for storing wiki content, appearance and functionality and would explore the Tiddler Philosophy of providing an “algebra of information”, which allows remixing “minimal units of meaning with richly modelled relationships between them” in languages beyond JavaScript.

On a related matter, I was reading @akkartik comment to the “The Web That Never Was” video, revisiting it and seing other related videos, including The Web that Wasn’t, and I was thinking, as happens to me with TiddlyWiki constantly, that such wikis are a glimpse of such alternative web happening now at small and beautiful scale: supporting transclusion, “end user” programmability, custom light syntax instead of verbose HTML, bi-directional links, among other wonders. That’s the path I want to explore now that, thanks to hypermedia revival, we can add to the wikis extensibility and dynamic web interfaces without user/dev facing JavaScript, and with custom languages following the HOWL stack: </> htmx ~ Hypermedia On Whatever you'd Like .

Wiki engines are a simple and extensible enough ground for this exploration, but what we have now that we haven’t since decades of their inception, is the possibility to develop for the web in a really (computer-y) multilingual fashion, if we add and hypermedia server, as I’m doing with Cardumem. Hopefully more experiments in that front will come and they will cure part of the melancholy expressed by @eliot in his NeXT, OOP, WWW, HTML post, related with an empowering informatics that is not widely spread among us. But as William Gibson said, “future has arrived, it is just not evenly distributed yet”. Grassroots communities are a fruitful place for inhabiting those futures, particularly communities in the periphery of capitalist/“development” vectors where everybody needs to do the last big thing (Blockchain, crypto, or AI, or as I like to call it Apparent Intelligence).

I’ll keep sharing our explorations here and in the mixed web that was/wasn’t.

Cheers,

  1. Minimal in comparison with the incidental complexity of its alernatives, let’s say Angular/React/Vue/Svelte + Jupyter + Git. ↩︎

  2. I have been relatively successful in knowing as little as I can about JS and forgetting that kind of quickly for over almost two decades. ↩︎

4 Likes