janek/nodal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add Intro and Fediverse thoughts

Browse source
This commit is contained in:
xeruf 2022-12-07 20:48:48 +01:00
parent 7be305139f
commit 23a56cafc7
3 changed files with 260 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
README.md
View file

@ -1,10 +1,25 @@
Months ago, I started my quest to refine task management. I was using Todoist at the time and wasn't satisfied.
I barely trusted it anymore - it was lacking capabilities I wanted, such as a wait date as well as a difference between scheduled and due. Since it is a proprietary service, extending it would have been very challenging.
# How-Todo?
This write-up and the accompanying markdown-files
are from 2020,
outlining my original thoughts and vision
amidst my studies as a Software Engineer.
I have since added Org-Files in 2022,
which outline a more grand picture
but also more refined details.
## Introduction
Months ago, I started my quest to refine task management.
I was using Todoist at the time and wasn't satisfied.
I barely trusted it anymore - it was lacking capabilities I wanted, such as a wait date as well as a difference between scheduled and due.
Since it is a proprietary service, extending it would have been very challenging.
I was also growing more accustomed and comfortable with the terminal and the UNIX philosophy.
So I started exploring the CLI task managers and found [taskwarrior] - it seemed the perfect tool at first glance, with great customizability and control. But it too turned out to have some fundamental flaws.
# The concept of trust
## The Concept of Trust
I believe I first heard CGP Grey using this term, but I have not found it anywhere on the Internet with this meaning.
@ -22,7 +37,7 @@ My problem is that I don't trust any of the systems I am currently using:
- CLIs: too verbose to use, didn't get me the information I needed in time
- web: too many clicks, too slow, not available offline, often unflexible
# Design
## Design
The most important rule: Everything is a task. There is nothing else.
@ -37,7 +52,7 @@ More fundamentals:
- UNIX philosophy: use plain text is possible, separate into independent modules
- Complete control: Inbuilt reports and attributes should use available configuration, so that the user can change fundamental parts of the system
## Task types
### Task types
There are essentially 4 types of things we do:
- tasks: things to be done once e.g. hand in an assignment, fix a bug
- activities: can't be completed e.g. browse the internet, gaming, spend time with family
@ -54,24 +69,24 @@ These basic types also incorporate other types:
Since "task" is one of these types, entities of any of these types can be called "items" within the implementation to avoid confusion.
## User Stories
### User Stories
- areas
- housework projects
- GTD
- Agile
### Reports I need
#### Reports I need
- Review active projects
- Find out tasks to batch when going out
- Find things I can do when I am (outside watching the babies e.g. cut nails | focused, wanting to do some (writing|programming) in the morning | unfocused in the afternoon e.g. check mails | taking a break from work on the computer e.g. do laundry | eating/snacking something e.g. watch a video/read a paper | listening to an audiobook e.g. digging, hang out the laundry)
# Inspirations
## Inspirations
## Taskwarrior
### Taskwarrior
I have been using [taskwarrior] for a few weeks now, but I am already starting to lose trust again. I don't work on most of the tasks I've entered, and if I do, I rarely remember checking them off.
### Issues
#### Issues
- A big issue holding me back is a missing notion of subtasks. You either have to use projects, dependencies or create a complete custom hack - either a script or hook. This also makes entering tasks more verbose as I have to specify multiple tags repeatedly which could otherwise simply be inherited.
- Recurrence is a longstanding issue, but can somewhat be solved by plugins: https://github.com/tbabej/task.shift-recurrence and https://github.com/JensErat/task-relative-recur
@ -80,17 +95,17 @@ I have been using [taskwarrior] for a few weeks now, but I am already starting t
- Keeping all reports aligned with custom attributes is a hassle, since you can't base reports off each other
- ids change whenever a task is completed, so you constantly have double-check or might complete a wrong task
### What it does well
#### What it does well
- Great customizability with reports, UDAs, DOM etc
- Great extendability with hooks
- Integrates with many tools (e.g. vimwiki, powerlevel10k, timewarrior)
# Links
## Links
[taskwarrior]: https://taskwarrior.org/
## Discussions
### Discussions
- https://kolaente.dev/vikunja/api/issues/1198:
Thoughts on Vikunja, my new hope.
- https://github.com/lyz-code/pydo/issues/73:
@ -98,10 +113,10 @@ I have been using [taskwarrior] for a few weeks now, but I am already starting t
- https://www.wired.com/2016/03/best-to-do-list-app/:
Maybe Technology won't help, after all...
## Projects
### Projects
- https://codeberg.org/equilibrium/equilibrium:
A Haskell project I started to link task managers,
unfortunately abandoned by now.
A Haskell project I started to connect task managers,
unfortunately abandoned now.
- https://tasklite.org/related.html:
List of CLI-oriented productivity systems
Should have a look at:

223
bonfire.org Normal file
View file

@ -0,0 +1,223 @@
#+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.

9
nodal.org
View file

@ -165,19 +165,22 @@ in our business use of Zulip,
which requires you to decide the receipients of a message
by posting it into a stream.
** Ideas
# Plantuml wireframes
Plantuml wireframes
Application Lifecycle Management (ALM)
Labels as Properties
-> dynamic interface
https://kolaente.dev/vikunja/frontend/issues/537#issuecomment-39747
Kanban config options:
- group by: assignee, property (label group, status, ...), date, parent task
- display levels: 1-X (range), only leaves
- display text levels: 1(self)-X
- ordering direction/sorting
# Application Lifecycle Management (ALM)
See also
https://kolaente.dev/vikunja/frontend/issues/537#issuecomment-39747
*** Copied Write-Ups
I have thought more about it, and I think the way to go will be to have no fixed Kanban view. Instead one should be able to create a kanban view grouped by a desired property, which might be the task status but could also be an assignee or the like, like in Notion.
Either way, there should be a way to add more task status options through which a task can be moved with one click as outlined above.