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% 的問題。

Twitter 的 MFA 可以加入多支 YubiKey 了

我手上有好幾隻 YubiKey,目前幾個有在用的服務都有支援同時綁定多組 U2F/WebAuthn 的能力 (像是 FacebookGitHub)。

Twitter 一開始推出的時候也可以支援多組,但在去年 2020 年八月的時候發現這個功能被拔掉,只能放一把進去。

我自己開了一張 ticket 定時回頭看一下有沒有修正,剛剛定期回顧發現這個功能被加回來了,而且官方的文件上也加上去了:「How to use two-factor authentication」。

翻了一下 Internet Archive 上的資料,看起來是 3/113/16 中間更新文件的...

手上有多把 security key 的人也可以處理一下。

印度威脅要逮捕 Facebook、WhatsApp 與 Twitter 的員工

The Wall Street Journal 上看到的,印度政府威脅 FacebookWhatsAppTwitter,如果不配合政府的要求提供資料並將內容下架,將會逮捕他們在印度的員工:「India Threatens Jail for Facebook, WhatsApp and Twitter Employees」。

這應該是透過上個月才剛過的法令:「Facebook, WhatsApp and Twitter Face New Rules in India」。

印度的市場太大,各家社群網站都想要進去,造就了政府的有足夠的能力跟這些大公司談判,而且是具有壓制性的力量。

在去年殺完 Tiktok 後,上個月擴權然後這個月反過來殺這些美國的企業。

美國政府不知道會幫到什麼程度...