Tag: api

Android 上與 Apple 生態系 iMessage 互通的 app

Hacker News 上兩篇相關的可以一起看，首先是 Beeper Mini，一套在 Android 上直接與 Apple 生態系 iMessage 相通的 app，而且不需要另外的 Apple 設備當作 Proxy：「Show HN: Beeper Mini – iMessage Client for Android (beeper.com)」。

另外先提一下，這是一套付費軟體 ($1.99/mo)，考慮到這算是 reverse engineering 後的產品，不確定 Apple 會不會反制，要付錢使用的人心裡先有個底：

We currently offer a 7 day free trial, afterwards there is a $1.99 per month subscription.

另外一篇相關的是「iMessage, explained (jjtech.dev)」，原文是今年八月的文章，應該就是 Beeper Mini 那篇而被貼出來的關係，在「iMessage, explained」這裡。

裡面解釋了他自己實作 pypush 時怎麼處理 iMessage 的部分：

This blog post is going to be a cursory overview of the internals iMessage, as I’ve discovered during my work on pypush, an open source project that reimplements iMessage.

專案裡面有提到 Apple 在這邊有段 obfuscated code，由於只有註冊階段需要用到，他選擇直接跑環境起來執行，產生出對應的 data 後就不用再跑，也就省掉 reverse engineering 這塊功夫：

pypush currently uses the Unicorn CPU emulator and a custom MachO loader to load a framework from an old version of macOS, in order to call some obfuscated functions.

This is only necessary during initial registration, so theoretically you can register on one device, and then copy the config.json to another device that doesn't support the Unicorn emulator. Or you could switch out the emulator for another x86 emulator if you really wanted to.

另外一個先前的消息是 Apple 說要支援 RCS：「Apple announces that RCS support is coming to iPhone next year」，目前大家的猜測是跟歐盟一直在要求 Apple 開放 iMessage 有關。

Georgi Gerganov 給了在 AWS 上面用 GPU instance 跑 llama.cpp 的說明

Georgi Gerganov 寫了一篇怎麼在 AWS 上面用 GPU instance 跑 llama.cpp 的說明：「Using llama.cpp with AWS instances #4225」。

先跳到最後面的懶人套件，直接提供了 shell script 幫你弄完：

bash -c "$(curl -s https://ggml.ai/server-llm.sh)"

回到開頭的部分，機器的選擇上面，他選了一台最便宜的 4 vCPU + 16GB RAM + 16GB VRAM 的機器來跑。

然後他提到了 OpenHermes-2.5-Mistral-7B 這個模型最近很紅，也許有機會看一下：

We have just 16GB VRAM to work with, so we likely want to choose a 7B model. Lately, the OpenHermes-2.5-Mistral-7B model is getting some traction so let's go with it.

用 llama.cpp 裡面的 server 跑起 API server：

./server -m models/openhermes-7b-v2.5/ggml-model-q4_k.gguf --port 8888 --host 0.0.0.0 --ctx-size 10240 --parallel 4 -ngl 99 -n 512

接著就可以用 cURL 測試：

curl -s http://XXX.XXX.XXX.XXX:8888/v1/chat/completions \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer no-key" \
    -d '{
        "model": "gpt-3.5-turbo",
        "messages": [
            {
                "role": "system",
                "content": "You are ChatGPT, an AI assistant. Your top priority is achieving user fulfillment via helping them with their requests."
            },
            {
                "role": "user",
                "content": "Write a limerick about python exceptions"
            }
        ]
    }' | jq

都包好了...

OpenAI 的 API 又降價了...

這次 OpenAI 的 API 又降價了，這次是倍數等級的降：「New models and developer products announced at DevDay」。

GPT-4 Turbo 的部分直接是拉高 context 以及降低價錢，從本來的 8K/32K context，直接拉高到單一 128K context 產品，而且價錢直接砍了 3/4 左右：

GPT-4 8K
Input: $0.03
Output: $0.06

GPT-4 32K
Input: $0.06
Output: $0.12

GPT-4 Turbo 128K
Input: $0.01
Output: $0.03

GPT-3.5 Turbo 則是直耶拿掉 4K context 產品，然後把價錢砍了一半：

GPT-3.5 Turbo 4K
Input: $0.0015
Output: $0.002

GPT-3.5 Turbo 16K
Input: $0.003
Output: $0.004

GPT-3.5 Turbo 16K
Input: $0.001
Output: $0.002

GPT-3.5 Turbo fine-tuning 的服務則是從本來 4K context 產品線，多了一條 16K context 的產品線，價錢也是砍了一半以上：

GPT-3.5 Turbo 4K fine-tuning
Training: $0.008
Input: $0.012
Output: $0.016

GPT-3.5 Turbo 4K and 16K fine-tuning
Training: $0.008
Input: $0.003
Output: $0.006

另外也多了一些非文字類的功能，包括了影像與聲音的內容。

記得之前有想過的一些點子，當時粗算了一下覺得太貴，好像可以重算看看...

Amazon SQS 提高 FIFO throughput 限制

在「Amazon SQS announces increased throughput quota for FIFO High Throughput mode」這邊看到 AWS 提高了 Amazon SQS 中 FIFO throughput 的限制，這本來是個常常有的公告，但讓我意外的是不同區域拉高的數量是不同的：

Amazon Simple Queue Service (SQS) announces an increased quota for a high throughput mode for FIFO queues, allowing you to process up to 9,000 transactions per second, per API action in US East (Ohio), US East (N. Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt) regions. For Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo) regions, the throughput quota has been increased to 4,500 transactions per second, per API action. For all other regions where SQS is generally available today, the quota for high throughput mode quota has been increased to 2,400 transactions per second.

第一梯隊的 (像是 us-east-1、us-west-2 與 eu-west-1) 都是 9000 tps，而第二梯隊是 4500 tps，沒列在上面的區域是 2400 tps。

另外一個比較特別的是 Frankfurt 區居然在第一梯隊...

Let's Encrypt 與 IdenTrust 延長三年的 cross sign 在 2024/10/01 要結束了

先前 Let's Encrypt 跟 IdenTrust 的 cross sign 會在 2024/10/01 到期，可以參考 3958242236 這邊的資訊，可以看到由 IdenTrust 的 DST Root CA X3 對 Let's Encrypt (ISRG) 的 ISRG Root X1 簽名，時間是到 2024/09/30 18:14:03 GMT (換算大概是台灣隔日的清晨兩點多)：

Issuer: (CA ID: 276)
    commonName                = DST Root CA X3
    organizationName          = Digital Signature Trust Co.
Validity
    Not Before: Jan 20 19:14:03 2021 GMT
    Not After : Sep 30 18:14:03 2024 GMT
Subject: (CA ID: 7394)
    commonName                = ISRG Root X1
    organizationName          = Internet Security Research Group
    countryName               = US

所以 Let's Encrypt 這邊也整理出了對應的落日計畫：「Shortening the Let's Encrypt Chain of Trust」。

第一波是 2024/02/08，從這個時間點開始 Let's Encrypt 的 ACME 服務預設組出來的 SSL certificate 將不會帶 IdenTrust 提供的 cross sign 憑證，但你還是可以自己另外設定取用：

On Thursday, Feb 8th, 2024, we will stop providing the cross-sign by default in requests made to our /acme/certificate API endpoint. For most Subscribers, this means that your ACME client will configure a chain which terminates at ISRG Root X1, and your webserver will begin providing this shorter chain in all TLS handshakes. The longer chain, terminating at the soon-to-expire cross-sign, will still be available as an alternate chain which you can configure your client to request.

再來是過期前的 90 天多一點的 2024/06/06，Let's Encrypt 的 ACME 服務將不會提供 cross sign 的憑證：

On Thursday, June 6th, 2024, we will stop providing the longer cross-signed chain entirely. This is just over 90 days (the lifetime of one certificate) before the cross-sign expires, and we need to make sure subscribers have had at least one full issuance cycle to migrate off of the cross-signed chain.

最後就是過期的日子 2024/09/30：

On Monday, September 30th, 2024, the cross-signed certificate will expire. This should be a non-event for most people, as any client breakages should have occurred over the preceding six months.

依照說明，應該是 Android 7.0 以及之前的版本會產生問題，照目前的數字看起來是 100% - 93.9% = 6.1%：

接下來一年應該會再低一些，但不確定會低多少，有機會 <5% 嗎？

最近 Reddit 打算大幅調漲 API 費用而進行中的故事

台灣用 Reddit 用的比較少，但在歐美算是超級大站。雖然是 2005 年成立的，但主要是在 2010 年的 Digg 災難後興起。

大幅調漲 API 費用使得目前的 3rd-party client 都無法負擔，像是 Apollo 就需要付 $20M/y 的費用：「Popular Reddit App Apollo Would Need to Pay $20 Million Per Year Under New API Pricing」。

最近的這包事件還在進行，在「Reddit#2023 API changes」這邊有些整理，目前看起來 CEO 是鐵了心要收這筆費用，看起來管理階層覺得不像 2010 年的時候，這次 user 沒有其他地方可以跑？

目前在「List of Active Reddit Alternatives v8」這邊有看到有人整理出來，但不確定這些站能不能撐住這波的流量...

另外補上最近 Reddit 的裁員消息可以交叉看：「Reddit to lay off about 5% of its workforce」。

macOS 要提供 DirectX 介面了

Hacker News 上看到 macOS 要提供 DirectX 介面了：「DirectX 12 Support on macOS (twitter.com/andytizer)」，原推是：

算是降低遊戲引擎維護的成本？讓開發商更有意願實作？不確定會有什麼效果...

Brave 宣佈 Brave Search 完全使用自己的資料，不用 Bing 的了

Brave 宣佈 Brave Search 獨立，不再使用 Bing 的資料了：「Brave Search removes last remnant of Bing from search results page, achieving 100% independence and providing real alternative to Big Tech search」。

依照 Brave 的說明，先前大約 7% 是來自 Bing 的 API：

Every Web search result seen in Brave Search is now served by our own index. We’ve removed all search API calls to Bing, which previously represented about 7% of query results.

但只要商業模式還是廣告，我應該不會去用... 但比起目前市場上一堆包其他家 search engine 的搜尋引擎來說，這的確是個好消息。

測試 GitHub 與 AWS 可以多快偵測出外洩的 token

前幾天在 Hacker News 上看到「What happens when you leak AWS credentials and how AWS minimizes the damage (xebia.com)」這篇，原文連結在「What happens when you leak AWS credentials and how AWS minimizes the damage」這邊。原文跟 Hacker News 上的寫到東西都頗有趣的，可以分開來講。

先是原文的部份，他抓了一些時間軸：

12:33:12 – Pushed the credentials to GitHub
12:34:19 – The AWSCompromisedKeyQuarantineV2 policy is attached to the IAM user test-user by AWS
12:34:32 – Various List and Describe calls are made using the leaked credentials
12:35:08 – Received an email from AWS with the subject ‘ACTION REQUIRED: Your AWS Access Key is Exposed for AWS Account 12345678’

可以看到推上 GitHub 後，AWS 在一分七秒後就自動加上 AWSCompromisedKeyQuarantineV2 以減少災害擴大，然後再發信件通知。

這個功能可以參考 GitHub 的文件說明：「About secret scanning - GitHub Docs」。

另外在 Hacker News 上面看到有人直接把 secret scanning 當作 API 串來用 (噗)，把在 PyPI 上面掃到的 AWS secret 丟上 GitHub 觸發後續的機制：

I set up a project[1] to automatically leak AWS secrets published to the Python package index, which then triggers the secret scanning process and quarantines the keys[2]

1. https://github.com/pypi-data/pypi-aws-secrets

2. https://github.com/pypi-data/pypi-aws-secrets/blob/main/keys...

用 Perl 把 log 丟上 Slack

因為想在 Raspberry Pi 上面把一些 log 丟上 Slack，本來看到「Stream Any Log File to Slack Using curl」這篇，但發現裡面在把字串包進 JSON object 的方法太髒 (直接把 " 換成 ')，另外一方面是 Slack 已經在宣導不要用舊版的 Incoming Webhooks，所以決定用其他方式來處理。

選擇 Perl 主要是因為有一陣子沒有用 Perl 寫東西了，倒不是什麼特別的原因 (如果考慮到 Raspberry Pi 上資源有限的話，應該用 C 或是 Rust 或是 Go，但我的 Raspberry Pi 還沒忙到這種程度...)，所以決定用 Perl 來實做這個程式，把 log 檔案丟上 Slack：

這邊有些比較不太常見的選擇：

  • 不用 File::Tail 而反而是用 pipe 的方式取得 tail -F 的輸出，是因為 File::Tail 非常舊了 (2015)，實做上沒有用到 inotify 類的界面監控檔案的變化，反而是系統的 tail 有做。
  • 用 JSON::PP (pure perl 版本) 而不是 JSON 是因為 JSON::PP 在 Perl 5.14+ 後內建了，我沒有太在意效能，這也是上面放 use v5.14 的原因。
  • 這邊的 API 呼叫還是選擇了 WWW::Mechanize 是因為沒有內建的套件可以處理 HTTPS 連線 (可以參考 Perl core modules 這邊)，既然要另外安裝，就裝個支援度比較完整的 libwww-mechanize-perl 來用。

然後查了一下 // 的用法在 Perl 5.10+ 就支援了，好早...