The worm-blossom related TODOs that came to Aljoscha's mind in a single let-me-write-down-as-many-todos-as-possible session in the autumn of 2025.

I've greyed out those task we did actually take care of, and greyed out and struck out those which we ended up deciding against doing.

• Willow:
  • Website:
    • Get into an update habit that does not require gigantic, perfect, awe-inspiring updates.
    • Update Rust section with our cleaned-up crate releases.
      • Update the docs to use those new releases.
    • Update to the new version of Macromania.
    • Update protocol comparisons page.
    • Clear all remaining TODOs and all open issues.
  • Rust Work:
    • Data Model:
      • Move out of workspace.
      • Rename to willow_data_model (underscores, not dashes).
      • Move relevant fuzz tests into this.
      • Feature-gate all ufotofu-related functionality.
      • Introduce traits such as Entrylike.
      • Change AoI to use Options for count and size (also change this in the spec).
      • Create a hierarchy of store traits.
      • Update doc comments, particularly for high-level introductions.
        • Document features.
        • Document trait hierarchies.
        • Be entirely consistent and thorough with links to the spec.
        • Way more doctests serving as examples.
      • Disallow public items without doc comment.
      • Expose helpful module hierarchy.
      • Move (relative) codecs to modules for their data types (purely internal).
      • Add SingleMinimum and DesignatedValue traits.
        • banish all uses of Default for parameter traits.
      • Add Successor trait, add a generic function for creating singleton ranges, remove the special-purpose ones.
      • Consolidate how to do parameter traits and their extensions. Reoccurring extension include:
        • quality of life (Ord, Hash, Clone, Debug, 'static),
        • minima, maxima, designated values
        • successors
        • codecs for relations and functions, absolute and relative
      • Use associated types for AuthorisationToken instead of generics (ask Gwil whether we tried that and it failed; there's probably a reason why we went with generics?).
      • Rename is_authorised_write to does_authorise.
      • Split parameter traits into simple version and fully-featured ones (extending the simple version and also codec traits, 'static, Ord, Hash, SingleMinimum, DesignatedValue, Successor, etc).
      • Publish relevant tutorials on the live website.
      • Do not use the willow-encoding crate.
      • Path:
        • Impl Display using the URI path encoding (also for Component and OwnedComponent).
        • Add macros for cerating well-known components and paths without unwrapping.
      • Check that all tests run and pass, including all fuzz tests.
      • Set up CI checks for all different combinations of enabled features.
      • Move all current stuff into a generic module, and make Willow25 things the main feature of the crate,
      • Proper types for Willow25, not just type aliases:
        • With impls of AsRef and AsMut for the underlying implementation, and an into method
        • Also traits specialising PathLike and friends for Willow25, implemented by the Willow25 types
      • Offer a LazyLock for well-known values (including the maximal willow25 path)
      • Use Bytes or Arcs for all the primitives to make them zero-copy
        • Though this might make embedded people unhappy
      • Maybe add a memory_stores feature which enables in-memory implementations of the store traits?
    • Meadowcap:
      • Update to accomodate breaking changes to the data model crate.
      • Implement changes analogous to those to the data model crate.
    • Discontinue Willow25 crate, moving its functionality into the respective spec-specific crates instead.
    • Stores: Figure out a principled way for doing these, probably around a hierarchy of traits of increasingly sophisticated features.
      • Features include Entry storage, Payload storage (Bab support, single-vs-multi-subslice storage), subscriptions (ephemeral vs resumable), summarisability.
      • Figure out the relation between in-memory and persistent implementations.
      • Figure out the relation between naive and efficient implementations.
      • Provide an efficient, persistent, feature-full store eventually.
  • Finalise the Willow25 spec for all currently existing protocols.
    • Requires some Bab work to be done.
  • Properly publish the URI spec.
    • Add Willow25 parameters for it.
    • Provide a Rust crate for it.
  • Create and publish the WTP (Willow Transport Protocol), a mostly stateless Request-Response-based protocol (essentially, you can GET entries and payload slices from a server, and you can PUT entries to and payload slices to the server).
    • Provide a basic Rust implementation for it (handling message encoding and decoding, but leaving message processing to the programmer).
    • Provide a store-connected Rust client implementation for it, which feeds response data into a store, and allows sending PUT requests populated with store data.
    • Create a store-connected Rust server implementation for it, which serves responses based on store data (and ingests data from PUT requests).
    • Create a networking-aware Rust server implementation which connects to and periodically RBSRs with statically configured peers (essentially a map from URLs/IP-addresses to areas to sync with them, plus desired frequency-of-sync metadata).
  • Update the WGPS:
    • Incorporate learnings from the WTP.
    • Clean up the Rust implementation and its worm-blossom-maintained dependencies.
  • IANA considerations:
    • Register the willow:// URI scheme.
    • Register a wtp:// URI scheme.
    • Register a wgps:// URI scheme.
  • Settle on whether Willow timstamps should be interpreted as TAI timestamps instead of UNIX time.
    • They really should, this is a question of compatibility guarantees and breaking-ish changes...
    • Update the spec (if not changing this, we should still point out the problem of leap-second repitition when using UNIX time).
    • Notify Joakim of the decision.
  • ChangeAreaOfIntereststo allow for zero as a valid max_count and max_size, by turning these fields into Options instead. I should have done this in the first place.
  • Design a peer-sampling-service protocol that can run concurrently to the WGPS to find new peers.
    • Can we make this usable beyond Willow? Might it be possible to have a single peer-sampling-service instance feeding peers to multiple, concurrently-running various p2p projects? If so, can there be shared infrastructure?
    • Incorporate notions of trust to protect against eclipse attacks and sybil attacks from untrusted peers.
• See the Bab funding we got through to completion.
• Multidimensional Geometric Search Trees:
  • Do a writeup (paper) on my multidimensional zip-tree generalisation.
  • Do a clean generalisation to Geometric Search Trees.
  • Implement this in Rust, use as a backend for a (persistent) Willow store implementation.
• Properly release the new version ofMacromania.
  • Hide all implementation details from the core crate, use export maps to present a clean interface.
  • Release as 1.0.0 on JSR as @macromania/macromania.
  • Create a really nice website.
  • Landing page with a solid introduction, crisp examples, links to websites built with it, and links to diataxis-style further docs.
  • Good API docs, possibly generated from a macromania package for easy referencing from the website content, and hyperlinked identifiers, and doc-comment (and possibly type information) tooltips.
  • Possibly write the tutorials/guides/other-content as literate typescript, turned by a macromania package into rendered content with nice tooltips and hyperlinking, and also running things as tests on compilation.
    • Probably use babel-js for parsing files into an AST, use // for markdown-ed prose, whereas /** */ remains for doc comments (which are of course rendered as markdown as well, but not converted into prose text) (this is my main gripe with LitScript, as it removes the ability to generate useful reference API docs (if only for IDE and website tooltips)).
• Write and/or update all the fun and useful Macromania packages to/for the new version of Macromania.
  • macromania-html: Almost done! Stuff for later (needn't be done for a 1.0.0 release):
    • Complete the datamodel verification for the few elements where I punted on it so far.
    • Add more html verification features over time.
    • Add statically-typed Macros for hopelessly overloaded html elements such as meta and input
  • macromania-names: Allow for hierarchical names (arrays of strings), add Macros for creating namespaces.
  • Also allow for completely separate, non-interfering universes of names (e.g., defref and a pokedex can coexist without collisions, could have completely different outputs). This used to be called namespace in the as-of-writing current version of this package.
  • Update everything that relies on names to support hierarchical names, in particular:
    • DefRef.
    • Pseudocode.
    • Probably the EncodingTemplate macro famility we use for the Willow website.
  • macromania-previews:
  • Figure out reliable iframe sizing.
  • Set a maximum iframe size and make the contents scrollable.
  • Make previews to an id in the iframe scroll to an appropriate position (the displayed region should start around 2em above the id-carrying element).
  • macromania-pseudocode: Write a parser for inputting pseudocode as pseudocode instead of a tree of Macros, turn the parsed AST into that tree of Macros, render them.
• Properly release UFOTOFU to the world, turning it from an internal idiosyncracy to a public idiosyncracy.
  • Make a breaking change toufotofu 0.7.x, changing how bulk producers and bulk consumers work.
    • Currently, the same buffer internals can be exposed to multiple independent bits of code, when using something like a SharedProducer; this can lead to the same buffer slots being worked with multiple times
    • Solution is probably to fuse the methods for exposing slots and those for marking exposed slots as having been processed into a single method, which takes a closure which returns the number of processed slots.
  • Create a nice web presence.
  • Port the paper-ish writeupto macromania, incorporate new learnings, add UFOTOFU-specific sidenotes everywhere.
  • Make docs more accessible.
  • Try to get more people to know about it.
• Write a blog-post on those ideas around bulk-transclusion serving as reification of document-aggregating UIs which I shared with Gwil that one evening.
  • Assess how much this impacts Rummager.
• Make Rummager real (Rummager is a Willow-powered, collaborative, multi-media data publishing platform allowing for arbitrary nesting as the only organisational principle).
  • Move from Discord to Rummager for Willow/worm-blossom community interaction.
• Will Dungeonocracy ever become a thing? Or that card-game we wanted to program? How about the updates-only-once-a-day/week microblogging thingy (though that might be integrated into Rummager)? The macromania-based protoype for writing nested summaries of content? The simple instruction set I drafted once, and the VM implementation for it? The three to four serious programming language ideas I keep carrying around with me? Ever use Valuable Values in the real world?
• Write my phd thesis.
  • Using the new macromania version, obviously.
  • Finish the current draft, fill in the details of a bunch of complexity analyses.
  • Possibly create alternate macros to produce LaTeX instead of HTML as output, for traditional publishing (and for submitting the thesis).
• Exercise regularly
• Eat Candy
• Ruminate