關於 twemoji.maxcdn.com 這個網址的一些事情

在「phpBB 3.3.10 Release」這邊看到這個修正,研究了一下發現原來有些故事在後面跑:

Update the emoji CDN: PHPBB3-17071

Twitter Emoji (Twemoji) 這個計畫是 Twitter 弄出來的 open source project,最主要是讓不支援新版 Unicode 的系統上可以改用圖片顯示出來 (畢竟 Unicode 一直在加字)。

其中提供的 url 是 https://twemoji.maxcdn.com/v/latest/twemoji.min.js,可以看到裡面帶有 MaxCDN 的資訊,算是一種廣告,但後來 StackPath 在 2016 併購 MaxCDN,接下來是在去年打算要淘汰掉 MaxCDN 這個產品線:「MaxCDN and SecureCDN are Retiring; Here’s What It Means for You」。

這件事情被帶到「Clarify MaxCDN URLs now that MaxCDN is retiring #556」這邊討論,但看起來沒有太多動作,後來在「Maxcdn has shut down, cdn not working anymore. #580」這邊又被帶起來討論,其中 Twitter 前員工大概提了一下情況,主要是當年他們跟 MaxCDN 有談過讓 MaxCDN 負責頻寬的部份:

@simplexx among all the things, twemoji has always been a Twitter service for the community.

At my times in there, we had a great agreement / deal with MaxCDN so that it's hard to blame the boss this time, as MaxCDN is a completely different company/story.

What I see is some poor attention to this project, as companies don't close from a day to another (usually?) but as we all know what's going on @ twitter, I can't really blame any of my former colleagues, or new arrivals there.

Please let's not make it a wall of shame for all the people that worked on this, thanks for your understanding (I've left 7 years ago or more, as example, I've got pinged by some follower and I'm just trying to help you out anyway).

另外也有人提到目前 Twitter 的溝通管道的狀況:

For what it's worth, while I was still there we were in talks with MaxCDN to have the same deal when they migrated to be Stackpath. Everyone who had worked on the deal with MaxCDN had left and left no record of that deal, so it was taking them a bit longer to work out than expected – MaxCDN used to offer free hosting to OSS projects, but Stackpath wouldn't be doing that. They were working on an exception for us, but any emails they send to our Twitter emails now get bounced, so I guess they could've gotten this sorted out before shutting down MaxCDN... but it's not like we're there on the other end to make it happen, so it appears we'll never know.

Anyway,現在是至少讓 twemoji.maxcdn.com 恢復到「會動」了,但情況變得很特殊,twemoji.maxcdn.com 這個網址目前是指到競業的 BunnyCDN 上:

;; ANSWER SECTION:
twemoji.maxcdn.com.     229     IN      CNAME   twemoji.b-cdn.net.
twemoji.b-cdn.net.      35      IN      A       23.248.177.58

但如果你真的打過去要檔案,會是 301 到 jsDelivr 上:

$ http https://twemoji.maxcdn.com/2/svg/1f525.svg
[...]
Location: https://cdn.jsdelivr.net/npm/twemoji@11.3.0/2/svg/1f525.svg
[...]

而 jsDelivr 目前是放在 Fastly 上:

;; ANSWER SECTION:
cdn.jsdelivr.net.       180     IN      CNAME   jsdelivr.map.fastly.net.
jsdelivr.map.fastly.net. 30     IN      A       199.232.45.229

但在 GitHub 的說明上面則是建議用 UNPKG

<script src="https://unpkg.com/twemoji@latest/dist/twemoji.min.js" crossorigin="anonymous"></script>

而 UNPKG 目前的 CDN 的部份則是 Cloudflare

;; ANSWER SECTION:
unpkg.com.              86400   IN      NS      anirban.ns.cloudflare.com.
unpkg.com.              86400   IN      NS      aron.ns.cloudflare.com.
;; ANSWER SECTION:
unpkg.com.              300     IN      A       104.16.126.175
unpkg.com.              300     IN      A       104.16.123.175
unpkg.com.              300     IN      A       104.16.122.175
unpkg.com.              300     IN      A       104.16.124.175
unpkg.com.              300     IN      A       104.16.125.175

指到 BunnyCDN 但是 BunnyCDN 只負責 redirect,然後也不是導到 UNPKG 上...

Twitter 宣佈要廢掉免費的 API 權限

昨天下午的時候看到這則官方在 Twitter 上提到的消息,要廢掉 free tier 的 API access:

但這邊提到的 paid basic tier 的價錢還沒看到公告。以「API Pricing - It’s very dark out here」這邊看到的價格,目前的 premium plan 超級貴:

這下看起來是真的得搬了,目前有好幾隻程式在上面跑 :o

Twitter 新政策禁止推廣其他社交平台的連結

看到 Paul Graham 這個宣告:

裡面提到的新政策在「Promotion of alternative social platforms policy」這邊,直接禁止其他社交平台:

At both the Tweet level and the account level, we will remove any free promotion of prohibited 3rd-party social media platforms, such as linking out (i.e. using URLs) to any of the below platforms on Twitter, or providing your handle without a URL:

  • Prohibited platforms:
    • Facebook, Instagram, Mastodon, Truth Social, Tribel, Post and Nostr
    • 3rd-party social media link aggregators such as linktr.ee, lnk.bio

Hacker News 的討論上面,Paul Graham 有回應 (帳號是 pg),他又提出了一些猜測與見解,包含了他覺得這個新政策會被收回:「Paul Graham is leaving Twitter for now (twitter.com/paulg)」。

I'm not leaving Twitter. It seems more likely than not that Elon will reverse the ban on links to other social media sites. I just don't want to hang out there in the meantime. Plus given the way things are going, it seemed like a good time to learn about alternatives.

I still think Elon is a smart guy. His work on cars and rockets speaks for itself. Nor do I think he's the villain a lot of people try to make him out to be. He's eccentric, definitely, but that should be news to no one. Plus I don't think he realizes that the techniques that work for cars and rockets don't work in social media. Those two facts are sufficient to explain most of his behavior.

He could still salvage the situation. He's the sort of person it would be a big mistake to write off. And I hope he does. I would be delighted to go back to using Twitter regularly.

不過的確如他說的,這是個好機會嘗試其他的 social network...

難得看到 John Resig 的 Blog 更新,在講 Mastodon

jQuery 的發明人 John Resig 已經超久沒更新 blog 了,雖然有訂起來但沒想到會看到他更新:「Twitter vs. Mastodon」。上次的更新是 2016 年初,快七年了。

基本上裡面就是解釋 TwitterMastodon 的差異,然後順便介紹他自己的 Mastodon 帳號。

不過目前看了一輪,ActivityPub 的各種實做還是離理想差了一截,可能會先繼續龜著...

Twitter 的 2022 年架構 (?)

Elon Musk 自己貼了以後,有人把白板圖整理成數位圖後好讀一些:

不過心裡可以先有底,這是解釋給大老闆聽的架構圖,底層可能還會有不少東西是沒有在這上面的,尤其是其他重要的子系統,像是圖片與影音怎麼處理之類的。

先把圖拉出來看原圖大小 (可以自己點),比較清楚一點:

從最前端往後看,可以看到 TLS-API 被標成淘汰中,照圖上寫的剩下 Android 版本在用,後續應該是往 GraphQL 靠;另外內部有使用到 Thrift,但沒有標 gRPC,我猜是這邊的主線上沒有 gRPC 而已,其他系統可能還是會有。

另外是有些東西有標 next-gen system,應該就是正在做而還沒上線的東西。

Twitter 的 Tor Onion 位置

Hacker News 上看到「Twitter is now available on Tor (help.twitter.com)」這篇,講 Twitter 官方的說明裡面有提到 Tor 的 Onion 服務:「About twitter.com supported browsers」。

會用到的網址分別是:

看起來這些開頭為 twitter 的 domain 是撞出來的... 不過還是討問題,如果已經可以用 Tor 的話,exit node 應該夠用?

為資料庫提案新的 UUID 格式

前幾天在 Hacker News Daily 上看到的東西,今年四月的時候有人針對資料庫提案新的 UUID 格式:「New UUID Formats – IETF Draft (ietf.org)」。

在 draft 開頭有說明這個提案的目標:

This document presents new time-based UUID formats which are suited for use as a database key.

A common case for modern applications is to create a unique identifier for use as a primary key in a database table. This identifier usually implements an embedded timestamp that is sortable using the monotonic creation time in the most significant bits. In addition the identifier is highly collision resistant, difficult to guess, and provides minimal security attack surfaces. None of the existing UUID versions, including UUIDv1, fulfill each of these requirements in the most efficient possible way. This document is a proposal to update [RFC4122] with three new UUID versions that address these concerns, each with different trade-offs.

另外在 Hacker News 上有人整理出來,可以直接理解提案所提出的新格式是什麼:

A somewhat oversimplified summary of the new UUID formats:

UUID6: a timestamp with a weird epoch and 100 ns precision like in UUID1, but in a big-endian order that sorts naturally by time, plus some random bits instead of a predictable MAC address.

UUID7: like UUID6, but uses normal Unix timestamps and allows more timestamp precision.

UUID8: like UUID7, but relaxes requirements on where the timestamp is coming from. Want to use a custom epoch or NTP timestamps or something? UUID8 allows it for the sake of flexibility and future-proofing, but the downside is that there's no standard way to parse the time from one of these -- the time source could be anything monotonic.

這在不同的 storage engine 上面會有不同的討論,這邊先討論 MySQL 系列的 InnoDB,至於 PostgreSQL 的 engine 以及其他資料庫系統,就另外讓更熟悉的人討論了。

InnoDB 採用了 clustered index (可以參考「Database index」這邊的說明),也就是資料本體是以某種定義的大小順序存放。

在 InnoDB 裡面則是用 primary key 的順序來存放資料 (沒有指定 primary key 時會有 fallback 行為),其他的 unique key 與 index key 則是指到 primary key,所以你可以看到 primary key 的大小也會影響到其他的 index key。

所以 128 bits 的 UUID 在大型的 MySQL ecosystem 實在不怎麼受歡迎,在 2010 年的時候 FlickrTwitter 都有發表過 ticket system:「Ticket Servers: Distributed Unique Primary Keys on the Cheap」、「Announcing Snowflake」,兩個系統有不同的需求,但都是產生 64 bits 的 unique id。

其中 Flickr 的系統算是很簡單的,沒有要保證時間順序 (i.e. 先取的號碼一定比較小,以及後取的號碼一定比較大),就用兩台 MySQL 跑 active-active 架構,然後錯開產生的值:

TicketServer1:
auto-increment-increment = 2
auto-increment-offset = 1

TicketServer2:
auto-increment-increment = 2
auto-increment-offset = 2

到現在還是一個蠻簡單的解法...

Twitter 推出打賞功能

Twitter 推出了 Tip Jar,也就是打賞功能:「Introducing Tip Jar」。

支援多種支付方式,包括 BandcampPatreon 這種創作者平台,另外也支援 Cash AppPayPalVenmo 這些一般性的金流平台。也因為實際上的金流不通過 Twitter 本身,所以就只有金流平台會收取的手續費:

The services* you can add today include Bandcamp, Cash App, Patreon, PayPal and Venmo. Twitter takes no cut.

看起來像是帶去其他 app 而已,所以不會有 iOSAndroid 的 30% 或是 15% 的問題。