2. For a minimalist wiki engine, isn't redundant to have two scripting languages and two hypermedia frameworks/libraries Short answer: for the scripting part no, as YueScript is intended for the end user while Lua is for the developer, and because the first transpiles to the second, this combination will eventually cover a learning path between users and developres. For the hypermedia part yes, but HTMX may be replaced in the future with Datastar, once more understanding and limits of the first are reached, while we build the infrastructure for the second, particularly for real time apps.

Non FAQ Cardumem is inmature/unknown enough to not have any Frequently Asked Questions (FAQ), but here are some of the imagined ones to start with: 1. Why another wiki engine? There is plenty of wiki engines with variety of features and we have had direct experience with several of them (MoinMoin, Dokuwiki, MediaWiki, Tiddlywiki) since early 2000's until now. Because of that, we acknowledge the software crafmanship and dedication behind such creations from their developers and the communities around them. So, what is the Cardumem's differential offering that deserves to create even more sofware? Cardumem is proposed, in the context of the Grafoscopio community, where we have experimented with digital metatools and the notion of interpersonal wikis as a way to collect and care for personal and community knowledge and memory. Because of the connections of members in the Grafoscopio community with places in other communities and academia, our practices and infrastructures has been tested in different contexts: linguistic revitalizing for indigenous communities in the Colombian Amazonas, Role Playing games, diagnosis of community learning needs in information and communication technologies, and examples (1, 2) of personal blikis (blogs + wikis), among others. Our previous and current experience with wiki engines, made me wonder about new possibilities, considering that none of the previous wiki engines were: designed before the current increasing rise and awareness of hypermedia systems. designed with our particular needs, practices and context in mind, and even TiddlyWiki, the one that is the simpler and more fluent to customize, was reaching a "stress point" regarding our documentation workflows and the extension capabilities and learnability that the (primary) author of Cardumen, was intending for. Given that our needs, practices and workflows in the Grafoscopio community were feeding other communities and individuals, I thought that a deeper exploration would be interesting in order to adress the required tool evolution in Grafoscopio community and other possible future beneficiaries, like the communities and individuales that are using our customizations in Amazonas, the coffe region, Bogotá and maybe some other places, specialy in the Global South. 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.

New Syntax The relation between notation and thought has been expressed repeatedly: from the practical imposibility to multiply in roman numbers versus the easiness to do it with arabic numbers, to the convenience of changing between Leibnitz's and Newton's notation for derivates and how that makes some manipulations easier for particular context, to the Kenneth's Iversson's "Notation as a tool for thought" and its impact on APL and its successors. So, how a new syntax can make more explicit the Hipertextual Algebra we talked before and empower memory/knowledge hypertextual/hypermedia practices? Cardumem is an exploration of that inquiry. The proposed new syntax has the particular intention of dealing with the problems of TiddlyWiki's domain-specific languages (DSL) with its operators and filters that, due to TiddlyWiki's syntax and particularities, do not generate knowledge easily transportable to other contexts outside TiddlyWiki and viceversa, the knowledge you have from other programming languages/environments clashes with the TiddlyWiki's syntax and particularities. That means that the gentle curve that TiddlyWiki provides between being a content creator and a functionality creator within the wiki, with the smooth transitions between lightweight markup languages, macros, filters and operators, is limited in the future, if one wants to use those concepts in a more general way or mix them with knowledge coming from other programming environments/languages. With Cardumem, a DSL could be implemented, which would also be simple to learn, but which embodies more general concepts such as functional programming, pipelining, data injection and transformation, and which can be more easily reused and transported in other contexts. In this way, the gentle learning curve described above is preserved, while being generalized at the same time. The new syntax3 is provided by YueScript and Mustache logicless templating system, so expressions like this should be available to select all units of information (called Dumems in Cardumem) tagged as "member", randomize them and apply a particular template/style: tagged("member") |> ramdomize() |> stylize("MemberTemplate") As you can see, the readability should be greatly improved over other wiki engines (including TiddlyWiki) and composability should be made more explicit. Because of that and the hypermedia metatools approach, we hope that syntax encourages the exploration of new pragmatics and semantics, so more people traverse the gentle curve between content and functionality creator, while exploring the "algebra of hypertext" in their particular projects, like the ones we had with other wiki engines: Personal Knowledge Management, interpersonal wikis (1, 2), web portafolios, linguistic revitalization in Colombian Amazonas, community's memory, role playing games, among others

Cardumem Wiki Cardumem is a wiki engine that continues TiddlyWiki's pioneer and long lasting exploration of an "algebra of hypertext", but goes beyond the JavaScript ecosystem, by reimagining such exploration from a Hypermedia Metatools approach. In a sense, Cardumem is a homage to TiddlyWiki, while (re)thinking/extending its deep ideas from another angle. Cardumem is a prototype of a minimalist extensible wiki engine, inspired by TiddlyWiki and backwards compatible with its data, made by combining Lua/YueScript + HTMX/Datastar, for server-side hypermedia programming, instead of client-side JavaScript. Cardumem tries to introduce new syntax for what Jeremy Ruston, author of TiddlyWiki would call1 an "algebra of hypertext", while supporting various of the pragmatics (practices) we have in several communities and projects that already use TiddlyWiki, and hopefully empowering the practices we care more about and introducing new ones. With the new syntax we try to support a similar gentle curve between being a content creator and a functionaly creator, like in TiddlyWiki's while implementing a more parsimonious design with syntax/concepts that can be applied more fluently outside our wiki engine (like data piping, templating and functional programming). A metatool is a tool that is used to describe, build and modify itself and eventualy other tools. Because of that, metatools are particularly useful to build custom workflows. While Cardumem at the moment is not build in itself, one important objective is to use the lessons of the Grafoscopio community building metatools, to boostrap first the usage of Cardumem in a particular community and then the meta properties of the tool, so it can be modified for such community. It that sense ours is also a practical and embodied inquiry and reflection in resonance with the Malleable Systems Collective (in fact, we found such collective after finishing the PhD research that conduced to the Grafoscopio metatool and community around it)

And because our (digital) prototypes try to be used/validaded mainly by communities instead of by academic peers, we need to care about the practicalities of such prototypes and their insertion in the communities. In my experience, this practical insertion could happen via two complementary strategies: the encompassing one and embedding one. The encompassing strategy could be exemplified by the Smalltalk variants, like Pharo or GToolkit, with their OS and IDE rolled into one approach. Here, a single computing experience includes "everything" a community artifact could need: object networks acting as "app(s)"3, persistance, data formats, IDEs, graphical stack, debbugers and so on. The practicalities are related with the collapse of incidental complexity when the community has a single metatool to bridge their other tools and workflows. We use what I call "interstitial programming" to bridge socio-technical systems by changing what happens in the gaps/bridges between them, instead of changing them from inside. This was the approach I followed with Grafoscopio, since late 2014 and early 2015 until present day, with pretty good results and fluency, allowing us to make several prototypes and empowering practices convering diverse needs: from self (PDF/web) publishing, to civic tech and political oversight, community learning and memory, amont other themes (chosing needs and topics in resonance with the community is key in having this prototypes as living artifacts in such community). The embedding strategy could be exemplified by Lua and its variants, like YueScript. Here, an already existing tool/experience is extended from inside or by complementing and then replacing an existing tool/practice, and while this contrast the "interstitial" approach mentioned above, still shares the concern of dealing with needs felt in the community in its current workflows and tools. This is the strategy I plan to explore this year, particularly regarding the publishing workflows/formats of several local grassroots communities, and to compare with how I'll be implementing part of such ideas in Grafoscopio (keeping on with the encompassing strategy). 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 JavaScript4 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 (for more details and links to the TW's community discussion visit the previos link). So, 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. While learning Lua and YueScript, I frequently miss a lot of the code liveness and the interactive documentation of the "Argumentative Driven Development" (ADD? 🤔) that I already enjoy within Grafoscopio over Pharo/GToolkit. So I thought that my first job would be to implement some kind of minimal notebook publishing on Lua, inpired by Clojure's Clerk6 and Julia's Pluto, but quite more static, at least as the begining (see Boostrapping a Lua notebook for more details). But finally a minimal Lua long comment + "markup tag" was good enough to have my documentation in the Lua files to postpone the idea, while exploring the HTML interactive interfaces provided by HTMX. Instead the design has been guided by the needs I have with my students/apprentices in my classes this semester at the university and future workshops in the hackerspace. And it has been a pretty fruitful design space/practice, where UI and functionality emerge organically, with the lessons I need to learn to ptovide the experience I need/want. There is still a long path to walk, but the initial advances are promising. Let's see how I walk the exploration map sketched here in this pendular movement from emcompassing to embedding strategies and from abstraction about the to concrete implementations. I will document my advances in the entries to come.

When I zoomed out from our practices on critical code/data literacy using metatools and pocket infrastructures to reformulate them in the broader convivial computing, one of the emphasis was how to increase (inter)personal and community agency with artifacts and practices that where deeply rooted and concerned with specific communities in particular contexts, despite the generalizing possibilitities of the concepts and recontextualizing possibilities of the practices and artifacts. This is something that I found kind of abstracted in the Global North counterparts of this genealogy, in things like "the developers" or "the user", in contrast with The People of the Center in the Colombian Amazonas, the local hackerspace, a food soveraignity and solidarity savings collective in the Colombian coffe region.

This brought up, again, some thoughts about how most of the research in the Global South mainly produces practical interventions in dialogue and within grassroots communities and it tries to create localized impact there, with the community, while giving not so much relevance to the academic circuit and the classical metrics of knowledge impact2. Or said in other way, the impact of the knowledge is meassure mostly/mainly in the grassroots communities, particularly in the Global South, instead of the academic ones, particularly in the Global North, which makes such impact pretty localized and invisible elsewhere. One recent example of this is our microwiki for linguistic revitalizing in the Colombian Amazonas, which is more concerned with the application of the concept of malleability in that community to attend their more pressing needs and will produce an academic paper later as a secondary output. When knowledge circulate between Global South and Global North more fluently it's mostly in web forums and mailing list. But, the main knowledge artifacts are not in English and not in academic paper form, and instead they are embodied in the language and artifacts that benefits more the grassroots communities where such knowledge was co-created. This also means that, when we arrive to similar concepts or names, like convivial computing or metatools/malleability, usually we have traversed different paths and our attention is focused in different places/concerns, or that we have diffractive genealogies, following the term used Janeke Adama in her Living Books. This happened when I saw that the convivial computing in English from the North has been more focused in the computing part that in the conviviality part, in this diffractive genealogy.

Community agency and metatools insertion strategies Status: Published First draft: 2025-01-11 Publishing date: 2025-09-02 In August of 2024 I was invited by the National Library of Colombia to present a critical approach to IA and libraries and by the Javeriana University, where I work, to co-create a draft curriculum on education innovation for peers in other univerisities. For both invitations, I (re)formulated1 the concept of convivial computing, trying to give a broader intellectual framework to the open practices we do in the Grafoscopio and HackBo communities. As usual, those developments are presented in Spanish and outside the classical academic circuit as a Mindmap and/or a talk, instead of in English in an academic paper or in a conference talk.

Interstitial journaling is a productivity technique created by Tony Stubblebine. To my knowledge, it’s the simplest way to combine note-taking, tasks, and time tracking in one unique workflow. You don’t need any special software, but Roam Research makes it even easier to do thanks to the flexibility of daily notes. Interstitial journaling has had an amazing impact on my productivity and creativity, and I think many people would enjoy it. The basic idea of interstitial journaling is to write a few lines every time you take a break, and to track the exact time you are taking these notes. For instance: 10:04 - Going to finish the first draft of the mindful productivity article. 10:46 - I fell into a Twitter blackhole again! Back to work. 11:45 - Made good progress. Need to get ready for meeting with Charlie. 11:49 - Reviewed agenda and docs. Feeling a bit anxious, but I think it will go fine. Need to call Anna after the meeting to debrief. Notice the mix of goals (“finish the first draft”), self-awareness (“fell into a Twitter blackhole”, “feeling anxious”), self-review (“good progress”), and actionable items (“call Anna”)? I love interstitial journaling because it’s a great way to make your breaks more mindful. Proactive breaks: reflect on your previous task, plan for the next one, take your own mental pulse, jot down anything else that comes to mind so as to reduce your cognitive load.Procrastination breaks: become aware of these breaks and how long they actually take. When you create the habit of writing down all your breaks, it becomes easier to not open a new tab to “quickly” check Twitter. You don’t want to have to admit that failure to yourself. Your interstitial journal is not only a journal, it’s a to-do list, a note-taking system, and a way to track your time meaningfully. As I mentioned, you can keep an interstitial journal anywhere. Even a text file would work well. If you’re a Roam Research user, let’s see how you can easily set it up there. I’m saying “setting it up”, but really… The work has been done for you already. Keeping an interstitial journal in Roam Research In my beginner’s guide to Roam, I completely left out the Daily Notes section to keep things simple. Let’s now have a look together. This is what a daily note with interstitial journaling looks like.