#123 implemented a way to create a hypha with Mycorrhiza's interface, without following red links or using browser's interface. I did not accept the way it implemented that, though.

But we do need something like that. Here's what I think:

• A big green button on top labeled Create a hypha.
• It opens an editor with fields not only for text and edit desc, but for name too. This way users can think of content before name. This is important, actually.
• There should be a media uploading zone too, if the hypha is to be a media hypha.

Like in that pull request, the address should be /new. Sounds nice. People could bookmark this address.

Currently, the concept of a user page is quite limited. What do we have? There is a link to your user hypha (usually u/<username>) in our miserable top bar. There is a button in the editor tool bar that inserts a link to that hypha. History and recent changes have such links too. That's it.

Here's how we can extend it.

• Your user page would be the perfect place for the Log out button, which is, actually, nowhere to be found in Mycorrhiza!
• For administrators, the link to the admin panel would look great here!
• In the future, user-related statistics and search tools (such as Edits by this user, Feed of edits by this user) might be placed here as well.
• Add user pics?? Not today.

I also want to use the word profile for user pages. Phrases like your profile too.

I expect everyone to agree that the ideas in this message are worth implementing. If I'm wrong, please tell me why.

Currently, Mycorrhiza does not have an API designed for machines. Most routes are meant to be requested by humans through browsers. Even though we can make third-party programs request them, they still cannot get all of the information they may need, so we need an API.

An example of a route designed for machines: https://mycorrhiza.wiki/title-search-json/?q=u

Why JSON? Because this format is:

1. Simple enough to put up with
2. The most popular format for this task in the industry
3. Already used in Mycorrhiza

So, no GraphQL nor XML. No home-brew serialization format (even though the idea is compelling).

A schema might be good too: https://json-schema.org

How do we make it good? Dunno, never done that.

Here are the routes I want to provide for the API:

• /mycorrhiza tells what version of Mycorrhiza used and stuff like that.
• All of human-oriented routes should be copied. Any exceptions?

I've seen many services include API version in the route. I don't want to do this.

By the way, such an API will make alternative front-ends possible. Cool.

If you write a codeblock like that:

these are

3 lines

It'll render like this:

these are
3 lines

This is unwanted and is a bug.

It was promised that MycorrhizaWiki would provide advanced user management. This issue is devoted to the design of the users. I'll use RFC 2119 here to look cool and classy.

User groups

• Usernames MUST be different from groupnames.
• Each user MUST be part of one or more groups.
• Each group SHOULD be given just enough rights for them — not more. For example, group users SHOULD NOT be able to edit critical hyphae like templates.

Suggested groups

MycorrhizaWiki MAY ship with these groups preconfigured, but wiki owner MAY change them.

admins

This is the most powerful group. mycorrhiza, the wiki's avatar user, and the wiki creator SHOULD be here.

• Can view hyphae? Yes, all of them.
• Can edit hyphae? Yes, all of them.
  • Allowed MIME-types: All of them.
• Can rewind hyphae? Yes, to any revision.
• Can delete hyphae? Yes, all of them.

moderators

These are important users that were trusted with keeping peace and order on the wiki.

• Can view hyphae? Yes, all of them.
• Can edit hyphae? Only non-critical ones.
  • Allowed MIME-types: Safe ones.
• Can rewind hyphae? Yes, to any revision.
• Can delete hyphae? Yes, but no more than 10 in an hour.

users

Regular users.

• Can view hyphae? Yes, all of them.
• Can edit hyphae? Only non-system ones + own user page.
  • Allowed MIME-types: Primitive ones.
• Can rewind hyphae? Yes, to one of 10 latest revisions.
• Can delete hyphae? No.

guests

Unauthorized users are considered as part of this group.

• Can view hyphae? Only non-system ones + user pages.
• Can edit hyphae? No.
  • Allowed MIME-types: None.
• Can rewind hyphae? No.
• Can delete hyphae? No.

Overriding rights on per-hypha basis

admins SHOULD be able to override rights per hypha branches. For example, admin (∈admins) decided that hypha Secret plans and its subhyphae shall be unavailable for everyone but admins. They would make such request:

wiki/Secret%20Plans?action=set-rights&data="w:admins"&recursive=1

Edit, rewind and delete rights will be derived from write rights.

Another example. The aforementioned admin decided that everyone but guests and user fungimaster shall have access to hypha Happiness. They would make such request:

wiki/Happiness?action=set-rights&data="w>users;r:_;d,w>moderators"

Usage

When a user (or a guest) makes a request, MycorrhizaWiki SHALL match the user against per-hypha rights (if present) and then against per-group rights. If they don't have enough rights, they SHALL be informed about that and the request SHALL abort.

Storage format

Good old JSON of course.

TODO

• Design the query format
• Design the JSON schema
• Think what rights should exist (history access?)

In MycorrhizaWiki mycelia are used to organize hyphae in related namespaces. This issue is devoted to their implementation.

Mycelium traits

• Every mycelium has any number (0..∞) of hyphae.
• Every hypha is part of one mycelium.
• Every mycelium has one canonical name and any number of synonyms.
• Every wiki has one main mycelium.

Mycelium URL

• Address a hypha in a particular mycelium: /sys:about.
• Address subpage of the hypha above: /sys:about/more
• Address a hypha in the main mycelium: /How/does it work.
• Address a hypha in the main mycelium explicitly: /main:How/does it work.

Mycelium configuration

• There will be some things about that in config.json.

Just js toolbar to insert markup elements into textarea

I often use my initials — KAS — as my username: kas. Mycorrhiza insists on displaying this as Kas, which makes no sense. KAS would also be fine, but Mycorrhiza has no way of knowing this.

I created a page for DNS — the Domain Name System — but Mycorrhiza dsiplay this as Dns, which is incorrect.

I really like that Mycorrhiza casefolds the filenames and the URLs to all lowercase, but I would like that Mycorrhiza could trust that the user knows best when it comes to the capitalization of words.

PS: Behaviour above as of commit ae03dbc

When i transclude big image to my hypha, i often want to crop it or resize. It can be very useful feature :)

I decided to drop maintaining custom versioning system in favor of git.

Some notes:

• Go-git, the library I want to use for git operations (GitOps?).
• Supported capabilities of go-git.
• Imagine a situation: there's a img&.jpg and user uploads a png file. Currently the jpg file is deleted and png file is saved as img&.png. With git, jpg file shall be rename first with git mv.
• What revision indexing should we use? Based on commits or on ids?
• Commit messages will have additional information encoded in them.

Additional information in commit messages

It is encoded as JSON from 3rd line of commit message on.

JSON fields (more to be added):

• "user": String that tells what user made this revision. If not present, the revision is anonymous.
• "type":
  • "rename"
  • "delete"
  • "edit-binary"
  • "edit-text" Default value

See https://github.com/bouncepaw/mycorrhiza/wiki/Новый-формат-гиф

We use the quicktemplate library for almost all of HTML templating tasks in the project.

Contra:

• Yet another dependency (all dependencies fail and are not to be trusted)
• Yet another non-standard thing
• We have twice as many files (.qtpl and .qtpl.go)
• People are irritated for some reason?

Pro:

• The core idea of the library (templates are normal Go functions) makes sense
• The syntax of the templating language is very expressive
• The library is quite fast, they say

I do not think changing quicktemplate to any other non-stdlib templating solution is a good idea. But what about stdlib's html/template?

=> https://godocs.io/html/template

Contra:

• The API is ridiculous. You have to parse each template (and that may fail) and then you have to ‘execute’ it (and that may fail too). Simply unbearable
• If we use html/template, it will be easier to implement template configuration, which is undesirable

Pro:

• It is in stdlib
• If we store the templates as separate .html files, every text editor will have a proper syntax highlighting. Compare with .qtpl which requires additional configuration everywhere

So, what is better? Cross your sword!

Turns out, we need tags.

Tags should not be part of Mycomarkup. There will not be a tags {} element.

Our terminology is an utter mess. Gotta untangle that.

The biggest terminology concern about Mycorrhiza is hyphae. They are not going anywhere any time soon.

However, hypha kinds need some defining. Like, we have textual hyphae and hyphae with attachments with an optional description. Not everyone gets the difference between them. One reason for that is the terminology. Let's call the second kind media hyphae! Concise and easy to understand.

There are many uncertain places throughout Mycorrhiza. I want to locate them and uproot them.

The Russian translation is sad right now. No clear terminology at all! Fixing this part would be easier, because all Russian text is stored in one directory. Maybe we should copy the MediaWiki translation where we can? It's, like, the only wiki engine with a proper Russian translation as far as I'm concerned.

We should publish AUR package automatically use something like https://github.com/marketplace/actions/publish-aur-package-2. Also we may create mycorrhiza-git package. (This package will be updated after any commit on main branch)

Может в отдельный пекич оформишь?

Sometimes I need to write a long hypha, but saving it in the middle and jumping back and forth between the editon and the hypha is tedious sometimes. Also, the editor doesn't warn about unsaved changes, which is a big problem itself.

So, the possible improvements here are:

• Add 'unsaved changes' warning (purely frontend, first priority)
• Add draft feature for the editor
  • purely frontend: local storage usage, which keeps drafted hypha text and invalidates it if the original is different than on editing started. Simple, yet not very reliable and not cross-device.
  • backend-based: drafts are stored in user-named Git branches and commited on save. Conflict resolving is optional, diff display is enough for starters. But it seems harsh on disk writes and network (considering Dropbox Paper or Notion-like UX).
• Allow saving without jumping back on the hypha page (unnecessary, but adds comfort), which unlocks...
• Add toggleable autosave

As of commit ae03dbc I see the following when using the search box in Mycorrhiza:

1. Seaches seem to be case-sensitive.
2. A search with zero hits leads you to a 404 page, and you have to use the browser's back-button in order to return to the wiki.

It would be nice to have case-insensitive search so that you needn't remember the case of the title of all pages.

It would also be nice if a null-result lets you stay in the wiki and tells you that your search has no hits.

1. Configure a hypha for top bar links
2. That hypha shall not exist
3. Start the wiki
4. Create the hypha
5. Update the links

The links in the hypha are appended to the default links, while they should replace them.

If two users edit the last hypha at the same time, whoever finishes - that result will be saved. This is very bad and unpredictable behavior. You can solve it like this - when the user goes to the hypha editing page - for everyone else this page is blocked with an warning like "Someone is already editing this hypha, please wait." Or, simply notify the user about such a problem without blocking the page. The hardest option is to use different branches and allow the user to resolve merge conflicts.

Если два пользователя редактируют гифу одновременно, кто закончит последний - тот результат и сохранится. Это очень плохое и непредсказуемое поведение. Решить его можно так - когда пользователь переходит на страницу редактирования гифы - всем остальным эта страница блокируется с надписью вроде "Кто-то уже редактирует эту гифу, пожалуйста, подождите." Либо просто уведомлять пользователя о такой проблеме, не блокируя страницу. Самый сложный вариант - использовать разные ветки и позволить пользователю разрешать конфликты мерджа.

Mycomarkup supports rocket link syntax in addition to regular [[link]] syntax. It is a legacy feature from times when gemtext was used and it will be supported forever.

Today I've noticed a cool feature in Notion: embedded links. They look like that:

The engine fetches a title, a description, an image and shows them all together in a nice box. I think that'd fit rocket links perfectly.

One day I want to support Gemini front-end as well. It makes sense to display rocket links in gemtext render as is, without magic link embedding.

The current API is as such: there is a special module l18n (why L and 18? It's either I and 18 or L and 10, right?) and everyone calls it when needed.

While it's cool, it's hard to refactor and update (with new localizations, for example).

I want to try out a different l10n approach for views, along with #117.

Now you can't quote something like quatrain, cause there is no linebreak syntax and multiline quotes. My syntax suggestions:

1. Block

quote {
Lorem ipsum dolor sit amet, 
consectetur adipiscing elit,
sed do eiusmod tempor incididunt
ut labore et dolore magna aliqua.
}

2. Line break syntax (maybe other symbol)

> Lorem ipsum dolor sit amet, \\n consectetur adipiscing elit, \\n sed do eiusmod tempor incididunt \\n ut labore et dolore magna aliqua.

3. Merge quotes. Different quotes separates with empty line.

> Lorem ipsum dolor sit amet, 
> consectetur adipiscing elit,
> sed do eiusmod tempor incididunt
> ut labore et dolore magna aliqua.

Now you can add only rocket-links, but inline links needs more often.

Text decoration shortcuts (and toolbar actions) should detect whether the selected text is already decorated and remove the decoration, if so. Not add it again.

It seems easy, just needs some changes selectionWrapper function in static/toolbar.js.

I think I'll do a PR for it in a day or another.

1. Run wiki with empty wiki directory
2. Go to [your wiki address]/random
3. You will see "The connection was reset"

Sibling sidebar considered harmful. See also https://mycorrhiza.wiki/hypha/essay/on_hierarchies

The plan is:

1. Disable it by default. Those who used it heavily before will turn it on and get a warning (☝️ using the sidebar might harm you or something like that) in stdout. They are meant to slowly learn how to live without it. Those who are new to Mycorrhiza will be fine without it. This will happen in the next release.
2. Delete it, eventually. Not in a hurry.

A good alternative should be offered. It is totally fine without it and without alternatives (see Melanocarpa and Pescenomicon that live without them; see other wikis running other engines that work fine without it (Wikipedia might be a good example)), but here is what can be offered:

1. A cloud of tags. Has cute vibes and encourages people to have a complex tag system, which is fine, maybe. Gotta figure out tags beforehand, see #125.
2. User-configurable list of some hyphae that is the same everywhere. Like MediaWiki's sidebar. Something like the second row of the top bar, but vertical and more detailed. The presence of such a sidebar would make it possible to finally have a non-ugly top bar, see #78.
3. User-configurable maps of content, as described in this outdated book. Dangerous, because it might discourage hypha linking with links. Also, how do you put it into a sidebar?
4. List of backlinks.

Also, is it an ideology-breaking update? If yes, then it it's time for 2.0.

One of the killer features of MycorrhizaWiki is intended to be the so-called tree navigation.

1. At the most basic level, users should have links to all direct ancestors (for hypha Fungi/Amanita/Muscaria that would be hyphae Fungi and Fungi/Amanita) and to the direct children. It's also possible to show children of children recursively.
2. If we choose to go more advanced, we can also show siblings of a hypha (for the aformentioned hypha that would be, for example, Fungi/Amanita/Gemmata and Fungi/Amanita/Regalis).
3. If we choose to go the most advanced, we can show whole wiki tree.

So, what should we choose? I like the second option most of all as it has the highest power-to-weight ratio. I'll start implementing it soon, but perhaps the third one is better. Discuss.

Опционально запрещать просмотр страницы неавторизованным пользователям или разрешать его только для автора. Это позволит открывать личные вики в публичный доступ, закрывая страницы с личной информацией. Так же станет удобно работать с незавершёнными гифами - открывать их только по готовности.

[Google Translate]
Optionally prohibit unauthorized users from viewing the page or allow it only for the author. This will allow you to open personal wikis to the public by closing pages with personal information. It will also become convenient to work with unfinished hyphas - open them only when ready.

Currently content files are named like that: <n>.txt and <n>.bin. It was decided that it's not a good naming scheme.

If a revision uses the same binary data as a previous one, it is marked in struct Revision, but not in meta.json. It introduces this bug: if you change a hypha with binary data, the old picture is shown only until you reload the program.

What to do

• Save files with numbers in their stem, but with extension matching their mime-type.
• If it is hard to decide what extension to use, fall back to .txt and .bin.
• Save filenames to meta.json

A little UX quality-of-life improvement: offer user to create an empty template wiki by a separate argument, such as -template:

2021/05/17 16:37:24 Error: pass a wiki directory
2021/05/17 16:37:24 Error: or run mycorrhiza -template <path>

The template command would git init a new wiki and (preferrably) set it to support Unicode paths. As an ideal, it would also left a template home hypha with some tips on next configuration steps (such as run mycorrhiza -print-example-config etc)

https://en.wikipedia.org/wiki/Single_sign-on

Every hypha stores one or two MIME types: one for obligatory text data and one for optional binary data. This issue is related to #11.

I've divided text MIME types into these groups:

Unsafe

These are ones that can potentially do something scary. text/html and text/javascript go here. Also HTML inclusions shall be prohibited in safe formats I guess.

Safe

These are ones that have limited capabilities compared to the ones above. text/css, text/markdown, text/gemini, text/asciidoc and other lightweight markup languages supported by MycorrhizaWiki (which ones are we going to support though?). Some of them support transclusion (another thing yet to be designed). Transclusion of unsafe MIME types if the user has not enough rights shall be prohibited. A message like the one below will be shown instead of transcluded data:

You don't have enough rights to transclude Hypha with HTML.

For now everyone can use any MIME type!

It's nice to have it.

Here are the topics:

• Hypha
• Attachment
• Mycomarkup
• New features of 1.3
• Configuration help (for administrators)
• Other quirks

Edit the list above to add an entry to do or mark as done.

I'm making this issue to add the Documentation label that I so long for.

I've almost started to translate help documentation, when I've found out that I wouldn't be able to navigate it, as it is fixed to English. So it struck me that we probably should translate the frontend part of Mycorrhiza. I emphasize on frontend, because log messages should be left English as the most universal language.

I'm ready to self-assign to it, but I have some questions to discuss first.

My concerns are possible bloat, quicktemplate interoperation, l18n library choice, and language choice mechanism.

About the latter, we preferably should extract the locale from user's request and then fall back to English. Also, as an idea, one could set the default locale in their configuration.

About the l18n library, we have a few choices:

• gotext, which would require adding locales, which is less bloaty, as one could remove unused locales. Also, it is more general (gettext is common) and explicitly supports short codes (such as en, eo, ru).
• go-localize, which is generate-based, seemingly lean, though has to keep all the strings inside of the binary.
• go-i18n, which is the most functional and bloated. Can use external files.
• golang.org/x/text with low-level, yet flexible operation. Possibly, own i18n strings format.

BTW, x/text and gotext approaches would let us implement custom wiki-local locales.

Now, recent-changes feeds can be a bit spammy on active wikis. Some way to grop edits by certain period of time allows to keep an eye on wiki without spam. I suggest to add GET parameter to /recent-change{rss, atom, etc} page with period, for example:

• /recent-changes-rss?period=day - once per day
• /recent-changes-atom?period=2-hour - 12 times per day

Of course, if there is no edits, feed is silent

Opening wiki.domain/hypha/static/filename gives the option to upload text and attachments to wiki.git/static/.

Browsing wiki using w3m is good but editing pages does not work. We need to fix it.

Most of Mycorrhiza users have an unhealthy tendency to keyboards and everything related to them. I keep wondering why is that a case.

Nevertheless, it seems like some sort of keyboard shortcut support is needed.

Cons

• One can already Tab around. It has been tested, it works.
• One can use a keyboard-centric navigation assistance tool such as VoiceOver.
• One can install a special browser or an extension with vim-like browser navigation.

All of these three statements undermine the need for a shortcut system. Not like I care.

Pros

Are obvious.

Way 1. Access keys

It turned out there is a feature called Access keys built in browsers. Hotkeys without JavaScript, how cool is that!

I tried to find some recommendations or standards on the topic. An initiative called “Standard access keys” was made a long time ago. Nowadays, their site is dead. We can access it through Web Archive:

=> Standard access keys

You can read it, it's not too long.

I found it unsatisfactory. Here's what I'm thinking of:

• Numbers 1 to 9 to access the header links. 0 accesses your page or the login page.
• Letters v(iew hypha), e(dit), a(ttachment), h(istory), r(ename), d(elete) access the correspinding tabs.

The biggest problem with access keys is that they require modifiers. And they are different not only between OSes but between browsers too.

We don't have much design space and can only fit so much functions.

But no JS! Unless...

Way 2. JavaScript

Oh no! Our archnemesis! The nightmare brought alive!

The tool bar turned out to be nice. Let's have more JS.

Let's just drop modifier keys for most cases.

The letters mentioned above access the tabs. No modifiers.

Letters n and p navigate to next and previous hypha. Letter s navigates to superhypha, if there is one. Or maybe Ctrl+arrows? Gotta think about that.

Letter g is used like a prefix for go-to command: gh home hypha, gu user hypha, gl hypha list, gr recent changes... Numbers can be used to access the entries in the top bar. Note that with the default top bar some entries have two shortcuts: gh and g1 for home hypha, for example.

In the editor, Ctrl-Enter saves the hypha. Also, shortcuts similar to rich text editors could be made: Ctrl+B for bold, for example. This list requires more research so let's think of it later.

Now, cool time. Numbers 1 to 9 access the first nine links in the hypha on the screen! Not enough for you? Grab your most then, why do you have it then?

As you can guess, I like the second approach more. List your ideas in this issue.

This feature is not planned for the 1.2 release.

Currently, out logging is a mess.

We want to clean up this mess.

How?

I think a hash in recent changes should be link to full diff page. The page should have url /primitive-diff/<hash> but now this url doesn't work without hypha after hash, it reset connection or return 502 Bad Gateway if you use nginx.

No one likes the current top bar.

Let's address what is wrong with it now:

• Looks sad when it gets multiline, especially on mobile devices.
• It is hard to make all the entries fit one line along with user-related links (u hypha or login/register) and search bar.

What I want top bar 2.0 to have:

• Meaningful responsive design
• Everything fits
• Useful for navigation

Two-line approach

Here's what I though of. We have two lines:

1. Link to the home hypha, search bar, user links. I'm sure there is a way to fit them all on any computer screen.

2. Navigation links. More advanced than now, dropdowns supported maybe.

   The dropdowns should work without JS. We have the tag for that: <details>.

On mobile devices, it may look like that (top to bottom):

1. Home hypha link
2. Search bar
3. Uh some collapsible menu
   1. User links
   2. The navigation links. Any collapsibles inside should be uncollapsed beforehand I guess.

Default navigation links

If we take this approach, we will have much more space for the navigation links. What do we put there? Not much, I guess.

1. Recent changes
2. List
3. Random
4. Admin panel, for admins only

Configuration

The current approach with the special hypha shall be demolished and forgotten. Perhaps.

The sidebar approach

What if we take all the navigation links and put them into a sidebar to the left of the hypha section?

Well, it is possible, but I wanted to put TOC there...

Near links is a feature from the OddMuse engine I found quite useful.

=> OddMuse docs on near links

Before implementing near links, interwiki capabilities has to be implemented. In a way, near links is a syntactic sugar on interwiki links.

When configuring interwiki map, a wiki might be marked a sister site (near site?). I think it makes sense to limit the number of sister sites to just one.

The Mycomarkup parser, when encountering links to a non-existent hypha, asks the sister site if it has a hypha with the same name. If it does, it will link it. If it does not, the link will be red as it should have been.

Example. Your wiki is called Home, the sister wiki is called Sister. Home has hyphae Fruit, Vegetable. Sister has hyphae Vegetable, Stone, Grass. This is what links will resolve to:

• [[Fruit]] -> Home:Fruit
• [[Vegetable]] -> Home:Vegetable
• [[Sister:Vegetable]] -> Sister:Vegetable
• [[Stone]] -> Sister:Stone
• [[Horse]] -> Home:Horse, an empty/non-existent hypha

Makes sense to me.

This feature would work well for public/walled garden combos, such as my Melanocarpa/Cyberrachel pair.

Considerations:

• Sisterwikiship is a one-directional relation. Maybe we should rename it to something else. Fallback wiki? Origin wiki?
• Difficult changes gotta be made to the Mycomarkup library.
• How do we know what hyphae the target wiki has? For Mycorrhiza, we can provide a special API, sure. Other engines? Well, that will be addressed when interwiki in general is developed.

How to reproduce: try pressing h on any hypha page or Ctrl-B in editor, when using Russian or another non-Latin keyboard layout.

I've localized it to static/shortcuts.js, as its code uses key property to retrieve the pressed key, however we also have layout-agnostic code property (and which, now deprecated). We can redo the code to use these values for hotkeys (convert Key* and Digit* keys, and maybe symbols, and cast everything else).

As an alternative, we could enable users to add their own shortcuts and partly circumvent the problem (also improving QoL for user JS plugins). Or do both proposed things.

That is actually a common problem in a variety of software (e.g. Vim, and even Github).

Very often you need to type current date in your hypha. Such button can be on js - charged toolbar.

See #56 for the beginning of the conversation.

I suppose we do need such folder structure. In fact, I've done something like that for Cyberrachel already.

Also, it is easier to have a unique copy of Mycorrhiza for each wiki you have.

I often needs to open cheatsheet in different tab to write new things. It'll be super useful to have most used markup things under textarea on the edit page

Currently, untrusted editors cannot rename hyphae. Why not let them?

I believe it would be useful to set path to wiki folder in config.ini file. So it would be easyer to switch wiki. And provide more consistent user expirience

As of 1.8, Mycorrhiza supports three kinds of hypha kinds: empty, textual (text only) and media (media + text). The differentiation between them is done in a hacky way.

And here we want to bring tags (#125). Not gonna do that until there is a proper differentiation between hypha kinds on the type level.

I'll start working on that in a separate branch.