Publish the notes

notes/160-pde.md

@@ -0,0 +1,62 @@
+
+☐ Invoke ObservavleHQ cells as microservices / pluggable dice engines
+
+☐ Prototype a PDE running in repl.it  
+“All your projects, instantly live. On Replit, there is no "deployment" stage of your projects-- we instantly host all of your repls”  
+cf. https://docs.repl.it/misc/database (a shared stash that both the PDE and Sidekick can access?)
+
+☐ Prototype a PDE running on GAE and NodeJS
+
+sequence so far:  
+1) PDE filter fires in the shard  
+2) PDE server gets the message and replies with either  
+  a) a reply to the user that needs no further processing from the bot  
+  b) a modified (preprocessed) message  
+     (turning `/r jake's health + 2d2` to `/r 33 + 2d2`)  
+  c) not interested: server handler decided not to process the message  
+3) If there's a reply or a modified message, they're passed to Sidekick handler  
+4) Sidekick handler might log the PDE content and keep tabs on it  
+  It sends the reply to the Discord (allowing for HTTP keepalive)  
+
+☐ A command to register HTTP plugins  
+
+    /r pde $yaml  # cf. https://learnxinyminutes.com/docs/yaml/
+      id: $short_unique_base36  # If ID exists then the PDE is updated
+      channel: $id  # If the user knows the Discord ID then they're likely have some kind of access to the channel
+      url: $http_url
+      pk: $ct_pk  # If recipient's public key is present then Sidekick generates a key pair and shares the PDE public key
+                  # Recepient will need that public key to open the messages and to encrypt the replies
+      zstd: 3  # Compression level
+
+→ ☐ Error message if the user is not a known patron  
+
+☐ The question of moderation and of malicious content used to set the bot up  
+
+☑ Upload WASMs into channels  
+☑ `fn dice_io`: Load the set of WASM plugins for the channel.  
+☑ → implement `fn wasm_plugins`  
+☒ could] Get some positive V8 vibe from https://youtu.be/njt-Qzw0mVY.  
+☑ `fn dice_io`: Explore WASM interpretation (inline function).  
+☑ `fn dice_io`: Pass a WASM handler to `fn dice`.  
+☐ `fn dice`: Run over the `input`, executing the WASM handler and the nom_inline_dice_notation.  
+☒ → Communicate with Node.js via stdin/out pipe. ⇒ Hard to do around blocking I/O and with proper failure modes.  
+☒ → https://github.com/cloudflare/quiche  
+☑ → → Commit wasm-server.js for future reference and mention it in quic.md  
+☑ Consider reusing some of the [Cloudflare docs and tools](https://workers.cloudflare.com/docs/tutorials/build-a-rustwasm-function/) to program the WASM  
+☑ → How about using the Cloudflare workers to serve the WASM in the first place? That is, instead of running the Node.js locally we'll simply host the WASMs as the Cloudflare workers! Meaning that the users will be able to develop Sidekick extensions with any HTTP server, Cloudflare workers is simply a solution we'll use as an example and for our own development experiments ⇒ They're working fine, though one needs to proxy a site via the Cloudflare to get the workers.  
+☑ → Evaluate https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws-lambda/  
+    They have [VSCode extension](https://aws.amazon.com/visualstudiocode/)  
+    They have S3 and DynamoDB and Simple Notification Service  
+    ⇒ Amazon created an EC2 instance to host the lambda, which has to be kept up and running for the lambda function to work (and was pain in the ass to disable), which is kind of different from on-demand computing I expected of it. And it's weird that they seem to take money for both the instance and the lambda computing time, and 100ms minimum at that.  
+☐ → Try Node.js on Google App Engine; and/or https://cloud.google.com/functions/docs/  
+☐ → Try https://glitch.com/create  
+☐ → Try http://heroku.com/ (https://github.com/emk/heroku-buildpack-rust)  
+☒ Communicate with Node.js via HTTP  
+☑ Move shard-handler communication to HTTP, https://github.com/ArtemGr/Sidekick/issues/195  
+☑ → Hyper server, [fast](https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext)  
+☑ → Port `ShardStatusPt::dispatch`  
+☑ Move SQLite synchronization to HTTP  
+☑ Move mobile-handler communication to HTTP  
+  We should eventually use something like the https://pub.dev/packages/firebase_messaging to get notifications, in order to save battery and traffic and RAM, but for now we can just reuse the bidirectional HTTP communication, leaving the push optimization for later  
+☑ → [Argo tunnel](https://github.com/cloudflare/cloudflared)  
+☑ → Long polling  

notes/191-mobile.md

@@ -0,0 +1,20 @@
+
+☐ Document the HTTP API and share it with Fraks
+
+☑ Receive text input from mobile app  
+☑ “/r bind app” on any private channel → generate a temporary (lm) bind key, return the public part  
+→ ☐ If the user is not a patron, suggest getting a patron key  
+☑ Check if the hash of the mobile message matches the stored hash of the public part  
+☑ If it is then share the bind secret (or hash / public key) with the app  
+☑ Send the secret with the polling requests  
+☑ Check the secret while handling `Poll` in `fn mobile`  
+☑ Refactor the schedule function to use the channel/author ID obtained  
+
+☐ Upload screenshot points into Sidekick  
+☐ Fuel certain schedule activities with points  
+→ ☐ Reaction that marks an activity as point-based (at certain scale)?  
+→ ☐ A different kind of reaction that also allows to go into minus? That way we can track the time spent together in a pairing activities that needs to later be reinbursed?  
+☐ Should be able to see and edit the (recent) history of point transactions, in order for Sidekick to be useable as a general purpose ledger  
+
+☐ Mention how Discord was down on 2019-12-07, https://status.cloud.google.com/incident/compute/19012  
+  The app allows accessing the bot even when the Discord is down.

notes/199-ro.md

@@ -0,0 +1,6 @@
+https://github.com/ArtemGr/Sidekick/issues/199  
+
+roll20 docu: “Special Case: Reroll Once (B,F) roCP”, https://wiki.roll20.net/Dice_Reference#Rerolling_Dice_.28B.2CF.29_rCP
+
+The `r` currently works as `ro`, I think.  
+We can increase the `lim` in `r` but I'm not sure what the `lim` should be, I've asked for opinions in several issues.  

notes/221-pp.md

@@ -0,0 +1,94 @@
+https://github.com/ArtemGr/Sidekick/issues/221  
+
+# todo list
+
+☐ Make a notifications branch  
+☑ Investigate http://www.cstr.ed.ac.uk/projects/festival/ ⇒ Online examples fail. Found http://www.cstr.ed.ac.uk/projects/festival/download.html and http://www.festvox.org/docs/manual-2.4.0/festival_6.html#Requirements  
+☐ Investigate https://cloud.google.com/text-to-speech ⇒ https://console.cloud.google.com/apis/api/texttospeech.googleapis.com/overview?project=trade-gae ⇒ Should use “default service account” per https://cloud.google.com/docs/authentication/production with GAE  
+cf. http://www.cross-plus-a.com/balabolka.htm (https://stackoverflow.com/a/45569850/257568); https://www.quora.com/How-can-I-add-voices-to-Balabolka  
+☐ Generate a feed for https://github.com/ca333/komodoDEX/issues/728  
+→ ☐ EdDSA signatures  
+
+# lfg & instant aid
+
+Time has individual meaning and coefficients, different rates (time for money, security, compassion, new experiences, etc)  
+In “wants to play ⇌ wants to play” the conversion might often be more direct (time for time)  
+In “has money and wants to hire ⇌ has time and wants to be hired” the conversion might involve the “time for money” rate, a kind of “margin trading” leverage for the time  
+We wonder if this might affect the interface, like when a person adds their waiting time to the exchange, or their expertize, etc. Transaction needs to have a positive ROI  
+
+☐ Make a “bonus” system for being online and waiting to pick up an aid/play (aka LFG) request, similar to how torrentday.com tracks the seeded torrents, in order for people not to feel discouraged from waiting for long  
+Aka “heartbeat”: there might be an easily accessible button somewhere that a user would press to signal that they are currently open for new matches, and using that hearbeat might have a small monetary and/or status/experience reward  
+☐ ROI is perception-based, the interface should facilitate that perception, like when we help people track the benefits they have gained from working together, a kind of a private journal perhaps, an optional and randomized feedback question (“what was cool about the engagement? what's the gain?”)  
+
+# outdated
+
+☐ Whitelisting; “Knowing that a user is playing Overwatch or listening to a certain artist on Spotify right now is innocuous. But, we believe the ability to track many, many users over a long period of time and profile their behaviors (not just what they play or listen to, but when they're online or offline, or at their computer vs. on mobile, or any random info they put in their custom status) is a potential issue”; “When you apply, we will ask you what features you are using the data for. We will approve or deny” - https://github.com/discord/discord-api-docs/pull/1307#issuecomment-576969633; https://blog.discordapp.com/the-future-of-bots-on-discord-4e6e050ab52e; https://support.discordapp.com/hc/en-us/articles/360040720412; “and like it or not this year there will be multiple changes that will be considered breaking changes for bots” - https://github.com/discord/discord-api-docs/pull/1307#issuecomment-581716513  
+→ ☐ ID verification at https://discordapp.com/developers/applications/209040908673482753/verification ⇒ Tried with a Russian ID, Discord sayd “We are unable to verify your identity because one or more of the documents you provided are unverified. Please try again” ⇒ With the international ID it worked… Now I need to describe the bot… https://hackmd.io/@artemciy/BJ29oy2DU ⇒ There was an error submitting all this. I've sent a support request, https://support.discordapp.com/hc/en-us/requests/7089456, https://mail.google.com/mail/u/0/#all/FMfcgxwHMjpbHlHzgfmpSRGxXcPQNKTq, https://www.patreon.com/posts/35797646 …  
+
+☐ Consider unsubscribing from the status events and using the mobile application to track the status instead  
+  This might help with solving the status abuse (case in point - MV keeping the pair programming signal for long), will allow for recipient selection (like when I want to talk with yurii but not with MV), etc etc  
+
+☐ Experimenting with Discord statuses shows that a certain number of people will “abuse” the system by setting the status and going away. This makes the Discord-based status largely unusable, just a few apples can radically change the way the LFG is experienced. The (mobile?) user interface should be protected from it, only allowing for a limited time status and hiding the AFK users.  
+☐ Similarly, we should take steps to discourage people from trying to book each other's time.  
+  cf. https://discordapp.com/channels/@me/654706300076425281/697873438097801256  
+  It's common to see messages along the lines of “If you are free later on today, could you lend me a hand?” This is completely backwards. Instead of using the non-verbal-like clues to catch the right moment the person is trying to load the rest of our day with another task for us to juggle.
+
+☐ Public HTTP API that gives external tools access to watched status updates  
+  Should be a first-class citizen, as the tools have extended information about when it's a good time to be notified of a watched status and how best to render notifications  
+
+☑ Switch to https://gitlab.com/artemciy/sqlite-mm  
+☐ Implement `tt_status` update callbacks, invoking a handler that would check the `share_activity`  
+  (That handler might be the `share_activity_step` except we're not calling it from a loop *yet*)  
+→ ☐ Detect when the primary replica didn't handle the updates  
+☑ Parse `/r share activity :busts_in_silhouette: with 668742126992883714 # PP`  
+☑ Start `share_activity_loop`  
+☑ fn on_presence_updateˢ: Implement the status reactions  
+→ ☑ Update `tt_status` if there is a `share_activity` entry  
+→ ☐ Invoke the hander, to be able to send/remove notifications and perform `share_activity` updates  
+  ⇒ We should probably use the SQLite update callbacks instead  
+☒ Shared HA master unavailability detection (cf. `track_time_step`)  
+→ ☑ Consider not using the activity loop and simply reacting to the status events instead  
+   Art sets :busts_in_silhouette:, then Maxim sets :busts_in_silhouette: - either only an immediate reaction right there,  
+   or also a delayed reaction (say, every N minutes)?  
+→ ☒ We could also reuse the `fn track_time_step` as is, invoking the `shared_activity_step` *from* it.  
+☐ Parse `/r unshare activity :busts_in_silhouette: with 668742126992883714`  
+→ ☐ "unshare" sounds as if we want to stop from notifying the `with` user about the activity, and maybe we should, to keep it simple  
+→ ☐ Consequently, when the activity is first shared we should share it both ways, notifying the `with` user  
+
+☐ Switching to a different channel with `/r track time` during an active status tracking leaves the previous channel's status message in an active state indefinitely, namely it doesn't have the 'zzz' inactivity marker.
+We don't want this to happen, though we don't know yet how best to fix this.
+
+☒ Verify that Sidekick can send a message to any user with a known ID or nick#hash  
+  ⇒ I've [added a Create DM implementation](https://github.com/ArtemGr/discord-rs/commit/388db7b903d2ef1b765d0eb41013f75b25a12503) that allows us to create or obtain a private channel to user. There is now an experimental forwarding in `fn mobile`. It works with Art, but should probably test it with users who didn't communicate with Sidekick yet.  
+  ⇒ So with Mateus `create_dm` worked NP but `send_message` failed with `Forbidden`. Looks like it's not enough to have a person in a friend list, one still have to [share a server with the bot](https://stackoverflow.com/questions/49358108/in-discord-js-can-i-send-directmessage-to-user-with-discordbot). After Mateus joining such a server the message came through NP.
+☐ Parse `/r share "pair programming" with 126848363613126656`  
+☐ Parse `/r share "pair programming"`  
+☐ Handle the `with` case  
+☐ Generate a message and try to send it  
+☐ If sending fails with `Forbidden` then share an invite link with the originating user  
+☐ Detect when the targeted user becomes available (Discord ought to send a new user event)  
+→ ☐ Track the identifiers of the users known to the bot?  
+☐ Continue the process when the user becomes available, re-generate and re-send the message  
+☐ Alternatively - just keep trying to send the message for a while  
+…  
+
+☐ Forward the private messages sent to the bot to _?
+☐ Forward the replies, identified by _, back to the user?
+
+☑ See if we're getting the status update events ⇒ Now we do  
+☑ Handle `/r track time`  
+☑ Reply with instructions (asking user to update the status)  
+☑ Catch status updates in the shards, updating a separate status table, skipping duplicated events  
+☑ Also catch when the user becomes idle, updating the same table  
+☑ Run a maintenance loop in the handler  
+☐ Use the SQLite callback to gather the IDs of recent status updates in order to process them faster  
+☑ If the handler is a secondary one, then use the SQLite callback to monitor when the changes to the tracking table last happened; if the secondary handler don't observe any changes in the tracking table for N minutes then it performs its own maintenance run  
+☐ Gather a list of entries to maintain: status updates ∪ *active* entries which hasn't been maintanied for N seconds  
+☑ In a replicated session go over them and: update the status and the time it was discovered; update the last maintenance time; update the time histogram (86400 / 60 / 10 / 8 = 18 bytes/day; or RLE)  
+☐ Go over the entries again, outside of a replicated session, and edit the reply messages, updating the time tracked and time remaining for a scheduled status update  
+  If the status time is expired then we delete the reply message and recreate it, in order to trigger notification  
+
+☑ Parse `/r share weeks 2020-1, 2020-2 from 789, 890 rate 33.3 with 123 # comment`  
+  cf. https://www.epochconverter.com/weeks/2020  
+
+☐ fishbowl reward (https://youtu.be/SROtK-LLZvQ?t=800, from 13:20 till 18:00) ?