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.

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?

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

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 :)

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

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.

Another trick is to use

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

to make the dweet play only when mouseover.

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.

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

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.