Twitter to X migration

[domenic]

Historically we used to use Twitter a good amount, including automated tweeting of every non-editorial non-meta commit to the standards. That functionality is currently broken (whatwg/participate.whatwg.org#351). We also used to hop on the main WHATWG Twitter account and tweet about various interesting things happening: https://x.com/WHATWG.

Assuming we're going to continue doing this, and one day fix the auto-posting of commits, then we should migrate all Twitter references to X. whatwg/whatwg.org#443 by @tylerjmorg took care of most of this for the whatwg.org repository. I think this is what remains:

• Visible changes:
  • Update various links in https://github.com/speced/bikeshed-boilerplate/tree/main/boilerplate/whatwg
  • Update https://github.com/whatwg/html/blob/main/FAQ.md
  • Update https://github.com/whatwg/html/blob/main/source
• Non-user-visible code changes:
  • Update the field in https://github.com/whatwg/sg/blob/main/db.json and its usage in https://github.com/whatwg/sg/blob/main/db.py
  • Update the usage of that field in https://github.com/whatwg/whatwg.org/blob/main/convert_sg_db.py
  • Lots of updates to the auto-tweeting code in https://github.com/whatwg/participate.whatwg.org
  • Update the field (TWITTER) used in https://github.com/speced/bikeshed-boilerplate/tree/main/boilerplate/whatwg and all of its values in every living standard

The non-user-visible code changes are not very worth it. Especially if we don't ever bother to actually make the per-spec accounts work again.

The visible changes are maybe worth doing anyway.

Or we could just give up on the per-Standard accounts and remove a bunch of this stuff.

[tylerjmorg]

IMO, I do find that having multiple accounts for each standard may be a little redundant UNLESS each update to the standards are recorded on X.

I think that most individuals may find that posting updates regarding the standards on social media (e.g., X, Mastodon, etc.) would be extremely useful considering the living document process. These methods may be the most convenient way for folks to find out about new changes (especially the big ones); if we work on making the posts functional again.

If this is general consensus within the group, I'm happy to help work on making those visible/background changes :).

[domenic]

I think we'd be happy to get your help on making these changes, especially the visible ones. However unfortunately making the X accounts work again will require work that only people with all the credentials, like myself, can do. And it's been hard to prioritize that work versus the many other things I have to work on. So it's still unclear when, exactly, we'll be able to get the accounts working again. (And if we do, how long they'll last, or if perhaps we'll get shut down randomly again.)

[GPHemsley]

Is it time to switch to Bluesky yet?

[domenic]

If someone wants to set up Bluesky bot automation, we'd welcome that addition.

[tylerjmorg]

That sounds like a fun project! Seems like a lot of scholars are moving over and Bluesky seems more welcoming of bots.

Do we want to set up the account(s) per spec? Or just one @whatwg.org account that announces every PR in each spec?

Also, how was Twitter's bot previously hosted? Bluesky recommends Heroku or Fly.io but idk what the steering group prefers.

[tylerjmorg]

Also, how do we wanna set up the account(s)? Was Twitter shared via Bitwarden or 1Password? Or if the steering group wants to set it up themselves?

[domenic]

I liked the one-account-per-spec setup we had with Twitter. But I can understand that it might be a hassle, so if we go with just one that's probably fine.

Since Bluesky allows using domain names as usernames, we should use either the spec's domain names (e.g. @html.spec.whatwg.org, @streams.spec.whatwg.org) or the top-level @spec.whatwg.org domain name. Presumably this would involve setting up some accounts and then telling the WHATWG admins what DNS records to add.

Previously we shared a text file with passwords among the WHATWG admins. I think the ideal setup would be to have the person setting up the accounts create the passwords, set everything up, and then let the admins change the passwords / API keys later. This would protect against the hypothetical future threat from the original person taking over the accounts and using them for nefarious purposes.

The Twitter bot worked via a GitHub webhook hosted on the participate.whatwg.org server: see this file and associated tests. If we can continue doing something similar, that is probably best, as then we have fewer services to manage.