☐ 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
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?”)
☐ 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” - discord/discord-api-docs#1307 (comment); 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” - discord/discord-api-docs#1307 (comment)
→ ☐ 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 👥, then Maxim sets 👥 - 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 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. 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) ?