stuff

content/tech/spec/activitypub/Follow.md

@@ -1,19 +1,28 @@
 +++
 +++
 
-Follows are realistically transient. it is therefore enough to:
+## what Follow is ideally like in theory
 
-- keep track of local state
-- mutate state based on activities
+- you send a Follow
+- they send you an Accept Follow as a courtesy, and Add you to their `followers`
+- you receive the Accept Follow and take it as a signal to Add them to your `following` (perhaps you can even show the Accept Follow as proof of this, if it was signed!)
+
+## what Follow is actually like in practice
+
+sharedInbox exists, and known follow relationships are used to calculate visibility on the receiving end (instead of relying on direct delivery). so now that Accept Follow actually matters... it's not just a courtesy anymore.
+
+because of this, Follows are realistically transient requests to update state. it is therefore enough to keep track of local state, then mutate state based on activities.
 
 if you receive an Accept/Reject Follow, check ONLY for the following:
 
 - actor
 - type == Accept/Reject
-- object.actor
+- object.actor == (you)
 - object.type == Follow
 - object.object == actor
 
 if object is inlined, you don't need to check that object.id is local. the above is enough information, PROVIDED THAT you have a local pending follow request. if you do not have a pending follow, then DO NOT process an incoming Accept Follow. however, you may receive a Reject Follow at any time, indicating that you should destroy that follow relationship. note that you may also receive an Undo Accept Follow by some implementations. this is discouraged but should be handled as well
 
-<https://github.com/misskey-dev/misskey/issues/9250>
+<https://github.com/misskey-dev/misskey/issues/9250>
+
+if you receive a Follow from someone you already Accepted, then send another Accept Follow to remind them. in practice, this usually means a state desync or database loss.

content/tech/spec/activitypub/shortcomings/_index.md

@@ -0,0 +1,2 @@
++++
++++

content/tech/spec/activitypub/shortcomings/collections-underspecced.md

@@ -0,0 +1,26 @@
+# collections are kinda underspecced tbh
+
+loosely inspired by the submission of FEP-5bf0 Collection sorting and filtering
+
+## filtering
+
+you could pre-create collections that contain a subset of items, but there's no way to dynamically do server-side filtering; this has to be done client-side by downloading the entire collection and creating any useful indices
+
+## sorting
+
+OrderedCollection is mandated reverse-chronological but it should have been possible to specify the ordering
+
+taking schema.org/ItemList and schema.org/ListItem as prior art:
+
+- `ListItem.position` is the index
+- `ItemList.itemListOrder` is the type of ordering
+	- `itemListOrderAscending`
+	- `itemListOrderDescending`
+	- `itemListUnordered`
+
+what might this imply is needed for activitypub?
+
+- `orderedBy`?
+	- what about multiple ordering criteria? SQL has `ORDER BY`
+	- actually, is a query language a good fit here?
+- `reversed`? more like `order: Ascending` or `order: Descending`?

content/tech/tasks.md

@@ -1,11 +0,0 @@
-+++
-updated = "2020"
-+++
-# Tasks
-
-## rough overview
-- Task list > Task > Subtask
-- Today / Upcoming / Anytime / Someday
-  - Today/Upcoming is for tasks with a due date or time
-  - Anytime is for tasks without a due date
-  - Someday is for tasks without a due date and lower priority

content/tech/xmpp.md

@@ -1,12 +0,0 @@
-+++
-updated = "2019"
-+++
-# XMPP
-
-## xmpp upcoming things
-
-### omemo 0.4.0
-labels for device keys, standardization under omemo namespace, works in group chats
-
-### mix
-whereas muc has clients connecting to rooms, mix has users connecting to channels. the main difference is bare jid user sends messages instead of client device -- this is better for multiclient usage.

content/wrong/todo-apps.md

@@ -0,0 +1,21 @@
+i kinda don't like most todo apps because they don't really mesh with how i think. maybe i just don't vibe with the GTD-inspired flow most apps use. the only app i've seen do tasks/todos in an actually useful way is Things 3 for iOS.
+
+### a better hierarchy
+
+Task List > Task > Subtask
+
+asana does this well imo
+
+### a better mental model
+
+Today / Upcoming / Anytime / Someday
+
+- Today/Upcoming: for tasks with a due date or time
+- Anytime: for tasks without a due date
+- Someday: for tasks without a due date and lower priority
+
+afaik only Things 3 does this?
+
+### what you can do as a workaround
+
+if your tasks app supports task lists within the same project/space/etc then you can make a separate list for Today / Upcoming / Anytime / Someday. it's not very precise but it at least works on a basic level