Do not autoplay audio dweets

[joeytwiddle]

We can detect an audio dweet if:

• It has been tagged #audio
• It contains code Audio or SpeechSynthesis or ...
• (It looks like it has a compressor, and the uncompressed code contains the above) But just the hashtag would get us 99% of the way

Behaviour: An audio dweet should just start off paused. There will be a 'Play' button the user can click if they want to start the dweet running.

Optional extra:

• A 'Pause' or 'Stop' button that can stop all started audio. One way to achieve this might be to override the Audio and SpeechSynthesis` constructors with our own functions that call the original functions, but also keep a copy of the constructed object in a global array, so that we can stop them when the button is pressed. This might also be an advantage when someone is editing an audio dweet. When they change the dweet, our reset function can stop all the existing audio output, to provide a clean slate for the new version.

[imscary]

That's easy to implement in js. Just get the comments using the api, check if "#audio" is there and delete the iframe autoplay attribute.

[lionleaf]

Using #audio would definitely get us pretty close, as if the author forgets to add it somebody else could. However, I worry we could then get people tagging random dweets as "#audio" as to disable autoplay.

Regex matching on the dweet would also get us pretty far, it will catch most normal audio dweets, but if somebody wants to they could always evade it.

We could override the Audio and SpeechSynthesis constructors with something that automatically mutes the sounds and presents an 'unmute' button somehow?

[imscary]

I suggest #pause instead of #audio. That will be good for massive dweets too!

[lionleaf]

The more I think about it I don't want this to be tied to a normal hashtag. If it is manually tagged I think it should only be the author + moderators that can tag such dweets (with a report button for the rest). If not you might get people who aggressively add #pause/#audio to other people's dweets against the will of the author in cases were it's not needed.

Also, @kipkat, slow dweets already time out :)

[imscary]

we can create a new concept, ##onlyCreatorHastag that prevents griefers from spamming #pause if you ##pause

[joeytwiddle]

If we want to do everything through hashtags:

• We could make #pause/#audio work automatically only if the comment was from the dweet author, or from a moderator.
• If other users comment #pause/#audio then that could act as a report.

There are actually multiple reasons we might not want to autostart a dweet:

• Pre-pausing #audio dweets (except I think we should just do that with #audio, more semantic)
• Pre-pausing #heavy dweets (although the loopbuster does help with this now)
• Pre-pausing flashy dweets, to assist epilepsy sufferers (default to true for Xen of course)
• Pre-pausing dweets so the viewer does not miss the start of the animation. (I can think of a couple of dweets where that might apply, for example a dweet with a story which runs only once, requires full attention.) Although a restart feature would make that redundant.

[imscary]

Another trick is to use

c.onmousemove=e=>{X=e.x};X;

to make the dweet play only when mouseover.

[joeytwiddle]

Anyway I don't mind if this is a checkbox for authors and a report button for users, instead of hashtags. But that would require touching python and adding some new things to the DB! 😱

How should we arrange the DB fields? Here are some possible alternatives:

• autoplay: true Defaults to true. We would need to migrate older dweets, or inject a default on retrieval.

• autopause: false Will create double negatives, but it may be convenient to have a falsey default. Alternative name: pauseAtStart

• autopauseReason: 'audio' A field to record why we pause it. In this case we won't need a boolean field.

• autopauseReasons: ['audio', 'heavy', 'flashy'] An alternative if we want to record multiple reasons why.

Should user reports be kept in a separate table? I guess so.

report: {
  reporter: 'u/katkop',
  date: 13431413,
  dweetId: 123,
  concerns: ['audio', 'flashy', 'heavy', 'made_by_xen'],
  status: 'accepted', // or 'pending' or 'rejected'
}

If we do require a reason not to autoplay, then we might also want a generic reason, for any cases we haven't considered.

[KilledByAPixel]

This would be good, because I'd like to see more audio dweets. I started to address this issue from within Dwitter by creating a small audio libary called DOMP.

https://www.dwitter.net/h/domp

[KilledByAPixel]

Domp handles starting and stopping audio when clicked on as well as some other handy stuff.

Would it be possible to have Dwitter create an default audio context the same way it creates a canvas context? It's basically the same thing as the canvas but for audio. This could give dwitter more control while also allowing more space for audio code.