nodal/bonfire.org

224 lines
8.7 KiB
Org Mode

#+title: Bonfire
* [2022-12-07] Federating Everything
** Groups
In response to my original write-up below,
I have been pointed towards a more appropriate distinction
of groups and tags:
A group is bound to an instance
and has a Fediverse handle.
This allows it (and thus its members) to be mentioned
and ensures communication stays private
within a private group
as it never leaves the instance.
(Hash)Tags on the other hand
are instance-independent
and cannot have members,
only subscribers.
** [[id:bonfire][Bonfire]] as a Task Manager
[[id:fediverse][ActivityPub]] is perfect for interactive task management
close to reality.
Let me explain.
When a message is posted,
one might select its type:
note, task, poll, offer, request and so on.
Each of these types is provided by an extension,
but underneath is a common schema which allows for graceful fallbacks
if no matching extension is available.
One option are textual keywords,
combined with metadata.
For example,
a task called "Finish the presentation"
with a deadline at the 8. December
might be represented as:
#+begin_quote
Task: Finish the presentation
Due: 2022-12-08
#+end_quote
But with an appropriate extension it might be displayed as:
#+begin_quote
⃞ Finish the presentation 📅 Due Tomorrow
#+end_quote
Ticking that checkbox would send an automatic message,
optionally prompting for a comment which might then be sent as:
#+begin_quote
Complete: 2022-12-07T19:48
Generated through reveal.js from Emacs Org-Mode, uploaded files to Nextcloud at LINK.
#+end_quote
The timestamp might be superfluous,
as it should match the send time of the message.
Detecting such a comment under the task,
the original message would display differently:
#+begin_quote
✅ Finish the presentation 📅 Completed Today
#+end_quote
An offer or request could be handled very similarly,
except that it usually involves multiple parties
and should use different icons.
By including a mention,
the task may be assigned to somebody
who can then also complete it.
Optionally the extension could allow anybody
or a certain group of users
to complete any task.
Posts on the Fediverse cannot be modified
and thus neither edited nor reassigned directly.
This limitation is actually a great feature,
as it always preserves an accurate history of what happened.
Descriptions, clarifications, findings and discussions
can easily be added as comments,
providing tight feedback loops.
Tasks may also be reassigned or rescheduled if permitted,
simply by sending a message with the appropriate syntax,
for example:
#+begin_quote
Assign: Somebody
Due: 2022-12-12
#+end_quote
This will mark the initial task as ⊟ obsolete
(one could even include a completion date,
thus the original task is marked completed -
for example if one department is done and pushes it to another).
This task then copies all non-changed properties
and transforms the message into a new task:
#+begin_quote
⃞ Finish the presentation 📅 Due Monday 👤 Somebody
#+end_quote
It might be sensible to add an indicator here
that this is an update of the parent task,
but that is not of primary concern.
With this,
tasks and communication can naturally intertwine,
as one often acompasses the other.
Notifications on new messages
and a task dashboard
ensure that nothing gets lost.
In the end,
the Fediverse is also just a hierarchical graph database :)
** Hooking Mails into the Fediverse
When we have this universal toolbox,
we want to be as inclusive as possible.
E-Mail persists as the most ubiquoutus federated protocol for decades,
with tools and workflows available for any platform imaginable.
So similar as in Zulip,
communicating with an instance
entirely by E-Mail
would be a great enabler.
This would entail
either running an own SMTP server
or polling an inbox,
with the latter likely being preferrable due to less complexity.
Either way, this does not have to be a locked-in decision
as it should also be handled by an extension.
Then a domain or subdomain
should be entirely reserved as gateway,
handled by the instance of with a star-redirect to its inbox.
It could thus both send and receive with E-Mail-Adresses
that equal the handle in the Fediverse.
It can accept private and group messages
if a match is found,
otherwise converting the username to a tag.
There should be filtering measures,
choosing between an Allowlist and Blacklist
which can match individual adresses
as well as whole domains.
It could be sensible to base this
on the moderation tools of the ActivityPub instance
to block spam from both protocols simultaneously.
Once an E-Mail is known to the instance,
it will receive responses on its own posts
and on mentions of its handle,
which might correspond to a fediverse handle as well.
There should also be the option
(in the mail footer, just like with a proper mailing list)
to adjust these notifications
and subscribe to every new message
or a particular group or hashtag,
just like a registered user.
This makes the Fediverse truly accessible to every generation.
* [2022-04-07] Making Team Chat Simple, Social and Scalable
** Analogies :noexport:
Ideally combines [[id:fediverse][Fediverse]] and [[id:messengers][Messengers]]
- Zulip :: structured communication, discussion, internal announcements
- Fedi :: resource sharing, inspiration, connection
Zulip is to jour fixe what Fedi is to huddle
** Current Issues
Unforunately, Zulip does not work too well with our startup:
1. the separation into channels is often not clear and can seem artificial due to our integrated nature
2. people often fail to determine the appropriate topic
3. participants feel compelled to read everything
4. the mobile experience takes too many clicks for a quick chat compared to a messenger
5. many externals that struggle to use it well, and guest accounts on many platforms worsen that experience
** Enter Real [[id:fedisocial][Social Networks]]
In ActivityPub, every post is a top-level-post, so no responses are lost in threads.
Nonetheless, one can reply to a post,
continuing a conversation to arbitrary depth without the need for a fixed structure
(fixes 2, as topics arise from reply chains -
bottom-up rather than top-down/on-demand rather than at the outset -
sparing cognitive load).
People can be pinged, posts can seemlessly switch from public to private or internal
(or even split up for topics with both public relevance and private information),
enabling integration of outwards social-media representation in the normal flow of communication.
With public posts, external collaborators can join in with an account from another server (fixes issue 5),
and if both server support hashtag permission management, even on sensitive topics.
*** Hashtags
But most important of all will be the handling of hashtags for classification and authorization:
Every post requires at least one hashtag, which will function similar to a Zulip Stream/Slack Channel/Mailing List/...
(fixes issue 1, as there can be multiple categorizing hashtags)
And they will also make groups superfluous.
Many hashtags will probably come and go, as is typical in social networks.
But any hashtag can be subscribed to, at which point it also functions as a shared channel -
without anyone who does not join having to be afraid of missing anything,
as they can still see the content in relevant replies, mentions, subscriptions of other people and the global timeline.
The icing on the cake is permission management:
Posts with a specific hashtag could be restricted to subscribers, which are of course invite-only,
so even sensitive topics can be discussed.
And last but not least, subscribed hashtags need an unread count - but only these (solves 3)!
The unread count on muted channels in Zulip induces FOMO and makes people use them the other way around:
Muting streams they need so they don't mindlessly check the messages there...
*** Conclusion
With ValueFlows from Bonfire, these posts can encompass tasks and more,
creating a single tool where ideas, discussions, tasks and updates (internal and external)
can be posted and collaborated on hassle-free,
while being available in an open format for further processing!
Thankfully, there is already a plethora of intuitive apps available at least for [[id:mastodon][Mastodon]]-compatible APIs,
enabling a personalized mobile experience (fixes issue 4).
** Alternatives
I am considering [[id:xmpp][XMPP]] via Movim, too, as it provides a familiar messenger experience, but it has one big issue: \\
Posts are confined to groups.
This means that new participants actively need to seek out the groups they want to be part of,
always have to decide where to post and thus sometimes crosspost.
Groups come and go, thus relevant content is easily missed,
as is typical in Slack and other Messaging solutions.
The biggest abomination of this are Telegram groups,
which are used like a bad social network
with constant annoying unstructured crossposts.