@baldemo.to contributed the domain and a lot of the early content and I hosted it on WikiJS
It’s pretty stale now and should get moved onto community infrastructure.
I’ve been hacking on lichen wiki in different ways and it’s pretty nice, including that all of the tools to host your own AppView are included in the repo
So, my suggestion is to
- host lichen wiki AppView using https://atproto.wiki domain (we’ll import the content)
- on community servers cc @InfraInternal
- get 2-3 people as leads on it
There’s other stuff like multilingual that lichen wiki doesn’t support that @vicwalker.dev.br did a bunch of translated content for (well port it over, maybe under atproto.brazil account?)
Lichen wiki does have a localized UI in French and Japanese as well as English.
We can of course have different accounts / groups that have their own wikis on there, but we’d focus on maybe even allow-listing accounts and send people to lichen.wiki if they want to show general purpose wikis.
@juprodh.me what do you think?
What this solves is saving the current wiki content somewhere more resilient (I’d make an account and use atproto.wiki as the handle / owner) and community hosted, and gives us a wiki to use as community infra.
And yes I am very much fishing for project leads on this!
4 Likes
Lichen dev here. A few notes:
Self-hosting
I haven’t built a deployable single-wiki setup yet, though I have a clear idea of how I’d do it. Today you can either (a) host the wiki on lichen.wiki under an atproto.wiki account, or (b) deploy a full lichen appview on community infra but that’s the whole social product (home, explore, profiles, network-wide firehose ingest).
Multilingual wikis
One wiki per language works today. Every wiki declares a BCP-47 content language, and the UI locale is separate (en/fr/ja). Editions can link to each other with cross-wiki wikilinks so porting translated content is possible now. What’s missing is a per-note “read this in another language” switcher.
Allow-listing accounts
Membership is per-wiki and owner-granted, so an atproto.wiki account that owns the wiki decides exactly who can write. There is no instance-level allowlist needed. And since a separate appview reads the same wiki.lichen.* records, it wouldn’t isolate anything content-wise. What a separate instance genuinely buys you is the domain, your own front page, and your own scope/moderation policy.
A better, single wiki self-hosting option is in the lichen.wiki backlog, and this use case would be a good reason for me to focus on it!
I’d like to know if there are specific features you’d need. And if you go this direction for the ATProto wiki, I’m happy to help you set it up.
2 Likes
Thanks @juprodh.me!
I set up an AppView for testing, was easy enough to run. Probably overkill to start with!
Yes I think having a domain is important.
Allow list was just thinking about whether we wanted arbitrary wiki’s displaying on a community instance. Could even allow editing and such but just not display anything that isn’t an atproto community wiki.
So imagine atproto.wiki, atproto.brazil etc being accessible, but not Boris’ Cocktail Recipes.
Oh great, I haven’t found the interface for that.
The big thing here is a couple of people leading the work.
I can fairly easily export the work so at some point I’ll do a test of that.