multiwiki

xj9/multiwiki.git

in the spirit of #against-consensus multiwiki doesn't attempt to provide a singular source of truth on any given topic. similar to git-ssb there will be a mesh of mutable <user>/<topic> resources that you can browse with the right client. the proof of concept client is being written in chicken scheme. so far, i have some basic api calls working and i'm hoping to have something that i can demo before the first walkaway utah meetup in october.

i still need to read up on the editable message stuff that @ev is doing in decent and get more familiar with how gatherings work as well. the goal here is to follow as many existing patterns as possible. i don't have a very clear picture of how i want to handle semantic data, but i've also never needed it in any wiki i've used. it would be very cool to have a wiki page for your local weather that is connected to a raspberry pi weather station that always shows you the current weather based on the data your station has collected. i'm sold in the idea, but i'm not sure how i want to express that in markdown.

i have a lot of ideas that i want to explore with ssb and this seems like a good place to get my hands dirty doing something useful and fun. i spend a lot of time writing and organizing notes. i'm honestly quite frustrated with basically every note taking system i've ever used. moinmoin is the option i hate least, but i still have a lot of issues with the whole "needs a server" thing. i'm very much looking forward to making multiwiki a reality.

why not electron/javascrit?

i mantain a large web app and a sister electron client for work so by the time i get home its sort of the last thing i want to put my time into. i don't hate javascript exactly, but i don't want to doom myself to a lifetime of the same old thing. scheme is fun and i have a strong preference for native applications over web anything.

2018-10-6

i've spent the last couple of days reading scheme standards documents and getting my dev environment organized. i've worked in other lisp dialects in the past (clojure and elisp), but scheme is a bit different. i published a Tomo RFC Draft for a batteries-included scheme dialect. i noticed that i'd keep reaching for functions from the standard libraries i'd used in the past, so i figured i'd organize them into a reusable module.

i have a basic interface working for pulling data out of sbot which just uses the cli for now and returns parsed json. not very complex, but i did end up going off on a big tangent trying to write a super elegant implementation of (comp f . fs) and then the whole relax rabbit hole.

(sbot command-string)

once i finish reading SRFI-64 i'll be able to get unit testing up and running, and start digging into nuklear and rendering messages.

2018-10-10

xj9/multiwiki.git has been on hold while i get the other project components up and running. very excited to start working with nuklear and fleshing out some of the ideas i have for writing native functional-reactive user interfaces.

things that got done

• i've refactored relax into its own git repo xj9/relax.git and started working on wrapping csc, csi, and chicken-install to use relax extensions.
• finally got parinfer working on spacemacs
• found an unfortunate footnote in the SRFI-18 unit docs for chicken scheme. looks like only Guile and Bigloo actually have pthread based implementations of this SRFI. there are some multi-core libraries for chicken, so at some point i'm going to have to write a multicore SRFI-18 module.
• i've written a little proof of concept script that creates a compressed egg (chicken scheme modules) cache in your ssb/blob store. this is work towards making a relax-specific integration between eggs and ssb and eventually a compiler agnostic frontend for writing scheme modules and applications.
• unit testing is still a work in progress. there are several testing tools and i'm working through evaluating all of the popular options.

its on the list of inspiring software :)

the goal generally is to remove infrastructure while keeping important and useful features! been busy doing research, hoping to make some tangible progress in the near future.

18312

a really simple wiki (with versioning) could be accomplished using ssb-webify or git-ssb which are already working sub-protocols within ssb. additional features like transclusion and other sematic wiki features are useful and important, but aren't required for replicating the wiki data. of course, having some standard way to interface with semantic data and these more advanced wiki features would be a good thing to have.

this is where it gets really easy to get lost in the weeds. rather than try to do everything at once, i'd like to focus on a more specific feature: replicating some editable structured data. i'm a fan of indental and tablatal because they give you the ability to define structured objects within some limits. indental, particularly, encourages a writing style where topics are broken down into small, digestible bites. both formats are easy to edit by hand so it would be feasible to create and edit wikis without booting up an ssb client.

similar to the projects i mentioned, multiwiki will allow you to establish a topic on a thread root. updates are published as backlinked messages that point to the new latest data. this is on a per-topic basis because of the message size limitations in ssb. on the viewing side: topics are keyed by label similar to webring/wiki and merged into a single view including notes from everyone within your FOAF range for that topic. links should be able to (optionally) specify a version of another user's topic feed. this could just be an editable text field, but i'd like to support working without running ssb-server and the structured format makes future semantic features much easier to implement.

18314

regarding two-way linking and hypertext, maybe all that's needed is a way to create mutable topic pages. we already have a form of hypertext in ssb (our markdown dialect), its already a step above html because of ssb-backlinks. could be something like:

{
  "type": "multiwiki",
  "topic": "stirling engine",
  // link to previous revision
  // some content field
}

a wiki view could show you the most recent versions of pages within your FOAF range. keeping with the #against-consensus concept, i would want to display topical content in a merged view similar to the webring wiki. could be nice to support attachments that can hold structured data in some set of useful, human-editable formats.

pages seem like a more approachable construct than semantic knowledge graphs. even more approachable than semantic wiki or just wiki even. wikis aren't that hard to grok, but i'd just like to have an easy tool for keeping notes and sharing information.

supporting longer articles could be an issue if the content is stored in-feed. backlinks and references would be good things to put in the feed for indexing purposes, but the markdown content and any attachments could just be (compressed) blobs. though i'm not sure that adding gzip to the dependency list is totally necesssary.

oh that looks really interesting! i'll have to dig into it some more when i have a sec.

i'm definitely of the opinion that you should parse more advanced data structures out of a collection of files and directories. the annotations that make it into the files should also be useful on their own, possibly even when viewed or combined with other markdown processing tools.