Federating knowledge: exploring ways to bridge wikis and notes

Join the workshop at #39C3!

NEW DATE: day 4, TODAY at 13:40 @ Free Knowledge Habitat Workshop Area.

Most people and organisations have their very own way of acquiring, organising, archiving, sharing, and collaborating on knowledge repositories. A broad spectrum of opinions and approaches resulted in a diverse and rich ecosystem of knowledge management solutions. Nevertheless, this also implies scattered and disconnected knowledge sources. What would it mean to build bridges among wikis and federate knowledge?

This workshop is going to be heavily centred on a twofold discussion, exploring the challenge of federated knowledge starting from two questions.

• What does it mean to federate knowledge repositories?
• Instead of pursuing a silver-bullet solution to embrace all use-cases, what would it mean to foster and enable interoperability for different software?

These questions stem from years of questioning and wondering how to integrate my personal note-taking and collective, participatory knowledge management at work, in organisations, institutions, and informal collectives. Recently, I began actively researching this topic as I started playing with the MediaWiki API to cross-synchronise my local Markdown notes and the XPUB wiki, the public learning wiki of the Experimental Publishing master. I am puzzled by taking advantage of the potential of a specific software (in this case, MediaWiki) while fearing of being locked-in.

Some further, more specific, insights and questions:

• Local-first approaches and software (e.g. Reflection)
• Interesting experiments based on existing protocols, such as Ibis
• What do we take of semi-open and obscure yet very cool initiatives like Anytype
• The power and the limits of plain-text: how to enable collaboration on simple Markdown files and build on top of it, as Obsidian does

Cc: @modal @p2panda @obsidian @wikimediaDE @dweb

#knowledge #FreeKnowledge #wiki #MediaWiki #API #Obsidian #Anytype #Ibis #IbisWiki #Reflection #CCC #Federation #federatedKnowledge #docs #PKM #knowledgeManagement #personalKnowledgeManagement #collectiveKnowledgeManagement #DWeb #decentralization #ActivityPub

Federating knowledge: exploring ways to bridge wikis and notes

Join the workshop at #39C3!

NEW DATE: day 4, TODAY at 13:40 @ Free Knowledge Habitat Workshop Area.

Most people and organisations have their very own way of acquiring, organising, archiving, sharing, and collaborating on knowledge repositories. A broad spectrum of opinions and approaches resulted in a diverse and rich ecosystem of knowledge management solutions. Nevertheless, this also implies scattered and disconnected knowledge sources. What would it mean to build bridges among wikis and federate knowledge?

This workshop is going to be heavily centred on a twofold discussion, exploring the challenge of federated knowledge starting from two questions.

• What does it mean to federate knowledge repositories?
• Instead of pursuing a silver-bullet solution to embrace all use-cases, what would it mean to foster and enable interoperability for different software?

These questions stem from years of questioning and wondering how to integrate my personal note-taking and collective, participatory knowledge management at work, in organisations, institutions, and informal collectives. Recently, I began actively researching this topic as I started playing with the MediaWiki API to cross-synchronise my local Markdown notes and the XPUB wiki, the public learning wiki of the Experimental Publishing master. I am puzzled by taking advantage of the potential of a specific software (in this case, MediaWiki) while fearing of being locked-in.

Some further, more specific, insights and questions:

• Local-first approaches and software (e.g. Reflection)
• Interesting experiments based on existing protocols, such as Ibis
• What do we take of semi-open and obscure yet very cool initiatives like Anytype
• The power and the limits of plain-text: how to enable collaboration on simple Markdown files and build on top of it, as Obsidian does

Cc: @modal @p2panda @obsidian @wikimediaDE @dweb

#knowledge #FreeKnowledge #wiki #MediaWiki #API #Obsidian #Anytype #Ibis #IbisWiki #Reflection #CCC #Federation #federatedKnowledge #docs #PKM #knowledgeManagement #personalKnowledgeManagement #collectiveKnowledgeManagement #DWeb #decentralization #ActivityPub

I think Matrix still has my favorite decentralized service username schema.

@user:domain.tld makes a lot of intuitive sense to me and looks really clean. It's really clear which part is the username and which is the domain without looking repetitive. It starts with an @ so it tells clients to pull up the username lookup when you start typing, but it doesn't get kludgy like other username schemas do.

user@domain.tld makes sense for email I guess because you can't really @ people inline, but it doesn't work well for other services because it doesn't start with an @ so it doesn't indicate to the client to pull up the username lookup. I'm curious how XMPP handles this.

@user@domain.tld that Fedi uses looks awful to me. I hate the double @'s, it just doesn't scan very well and looks silly. Maybe it's just me, but I feel like my username is being flanked by boobies. (Technically Fedi uses WebFinger/the email schema under the hood from the last example and the double @'s are just user-facing in order to trigger the inline username lookup, but meh, I'm including it.)

@domain.tld that Bluesky uses seems clean on the surface, but then you realize your username is (usually) just a domain name which is... weird. Then you're stuck making a subdomain for your username if you couldn't get a dedicated domain for it, so then it becomes @user.domain.tld or even @user.subdomain.domain.tld which is just, like, idk a lot of dots. It makes sense for ATProto because of how the DIDs work, but it's still not my favorite.

I know I've made this ramble before but I'm like Fedi handles where I'm hopelessly repetitive

#Matrix #MatrixChat #Federation #Fedi #Mastodon #ActivityPub #Bluesky #ATProto

@jwildeboer @sashin

Have you heard any recent updates on the federation? Last time I checked (a few months back) it seemed to be in the "nice to have" category but not particularly actively being worked on.

#git #gitForge #federation #ActivityPub #codeberg #forgejo

Sneak Preview for clj-threats - we have released the first version.

https://repo.prod.meissa.de/meissa/clj-threats

clj-threats is devops style tool for continuous threat analysis.
The system definition is compatible with threagile, but we added attack trees.

We will enhance the attack tree library while using this tool for the threat analysis for federated forgejo.

#clojure #forgejo #threat-modelling #attack-tree #federation

I think Matrix still has my favorite decentralized service username schema.

@user:domain.tld makes a lot of intuitive sense to me and looks really clean. It's really clear which part is the username and which is the domain without looking repetitive. It starts with an @ so it tells clients to pull up the username lookup when you start typing, but it doesn't get kludgy like other username schemas do.

user@domain.tld makes sense for email I guess because you can't really @ people inline, but it doesn't work well for other services because it doesn't start with an @ so it doesn't indicate to the client to pull up the username lookup. I'm curious how XMPP handles this.

@user@domain.tld that Fedi uses looks awful to me. I hate the double @'s, it just doesn't scan very well and looks silly. Maybe it's just me, but I feel like my username is being flanked by boobies. (Technically Fedi uses WebFinger/the email schema under the hood from the last example and the double @'s are just user-facing in order to trigger the inline username lookup, but meh, I'm including it.)

@domain.tld that Bluesky uses seems clean on the surface, but then you realize your username is (usually) just a domain name which is... weird. Then you're stuck making a subdomain for your username if you couldn't get a dedicated domain for it, so then it becomes @user.domain.tld or even @user.subdomain.domain.tld which is just, like, idk a lot of dots. It makes sense for ATProto because of how the DIDs work, but it's still not my favorite.

I know I've made this ramble before but I'm like Fedi handles where I'm hopelessly repetitive

#Matrix #MatrixChat #Federation #Fedi #Mastodon #ActivityPub #Bluesky #ATProto

Sneak Preview for clj-threats - we have released the first version.

https://repo.prod.meissa.de/meissa/clj-threats

clj-threats is devops style tool for continuous threat analysis.
The system definition is compatible with threagile, but we added attack trees.

We will enhance the attack tree library while using this tool for the threat analysis for federated forgejo.

#clojure #forgejo #threat-modelling #attack-tree #federation

I know #radicle project people will be at #39c3 but what about people working on forge #federation? I would love a world where we have strong competitive versions of both these ideas.

I know #radicle project people will be at #39c3 but what about people working on forge #federation? I would love a world where we have strong competitive versions of both these ideas.

This is something discussions on #Spotify tend to miss: most alternatives are corporate services that are not immune to #enshittification

@mirlo thinks #federation is the answer:

“We’re trying to federate #music marketplaces and music distribution platforms (..) if the instance that hosts your music starts to do things you don’t like, you should be able to transfer your data, and not lose anything”

@diyconspiracy

https://diyconspiracy.net/mirlo-interview/

Brygglogg.se is a homebrew recipe site where you can find, upload and build recipes for homebrewed beers.

It has some extra functionality like a label generator, a recipe specific timer, recipe analysis graphs and more.

It’s currently only available in Swedish.

I started working on making it as a ActivityPub federated service which would be fun to finish.

https://brygglogg.se

#homebrew #beer #recipe #ActivityPub #federation

This is something discussions on #Spotify tend to miss: most alternatives are corporate services that are not immune to #enshittification

@mirlo thinks #federation is the answer:

“We’re trying to federate #music marketplaces and music distribution platforms (..) if the instance that hosts your music starts to do things you don’t like, you should be able to transfer your data, and not lose anything”

@diyconspiracy

https://diyconspiracy.net/mirlo-interview/

#ORCID authentication, #OpenAlex integration, #Zenodo #DOI generation etc. This community owned open science example based on #Bonfire looks very promising. Have a look at https://openscience.network
#openscience #federation @bonfire

Good luck! In the long run, there is only one serious defense against DDoS and other attacks: federation. I’m really looking forward to @forgejo
supporting federation for repository forks and pull requests.

#DDoS #attack #federation #fediverse #forgejo #opensource