#

nostr developpement

(10 articles)

สิ่งที่ Game Dev อยากบอก (แต่ตะโกนออกมาไม่ได้...) พร้อม 3 เคล็ดลับเอาตัวรอด! 💀⚡️

**เชื่อไหมครับว่า... เบื้องหลังฉากสวยๆ และเกมเพลย์ที่ลื่นไหล มันถูกยึดโยงไว้ด้วยเทปกาว สายไฟ และแรงอธิษฐานของ Developer ทั้งนั้น!** นี่คือ 3 เรื่องจริงที่คนทำเกมเจอ (แต่คนเล่นอาจไม่เคยรู้) “ แค่เพิ่มปุ่มเดียวเอง ” = ประโยคทำลายล้างที่แท้จริง เพราะภายใต้ปุ่มนั้นอาจหมายถึงการรื้อโครงสร้าง UI ใหม่ และต้องไล่เช็กว่ามันจะไม่ไปพังระบบ Save ที่ทำไว้ กฎ 90/90 = พัฒนาเกมไป 90% แรกใช้เวลาตามแผน... แต่อีก 10% ที่เหลือ (ช่วงเก็บงาน/แก้บั๊ก) กลับใช้เวลาอีก 90% ของเวลาทั้งหมด! The "Unpredictable" Players = เราสร้างทางเดินอย่างดีให้ไปทางขวา แต่ผู้เล่นจะพยายามปีนกำแพงออกนอกแมพทางซ้ายเสมอR 💡 [Bonus] 3 บทเรียนสำหรับคนที่อยากเริ่มต้น Game Dev ไหนๆ ก็บ่นแล้ว ขอแชร์เทคนิคที่ช่วยให้ชีวิต Developer ง่ายขึ้นจริงๆ ครับ > 1. Keep it Small (MVP): อย่าเพิ่งเริ่มที่ "Open World RPG" ในฝัน ให้เริ่มที่เกมเล็กๆ ที่จบใน 1 อาทิตย์ก่อน การทำเกมให้ "เสร็จ" สำคัญกว่าการทำเกมให้ "ใหญ่" > 2. Version Control คือชีวิต: อย่าตั้งชื่อไฟล์ว่า Game_Final_v2_RealFinal.zip ให้ใช้ Git ตั้งแต่วันแรก เพราะถ้า Code พังตอนตีสาม คุณจะกราบตัวเองที่ทำระบบ Backup ไว้ > 3. Community Over Competition: ในโลกของ Indie Dev เราไม่ได้แข่งกันเอง การเข้ากลุ่ม Discord หรือโพสต์ลง Nostr/YakiHonne เพื่อขอ Feedback จะช่วยให้คุณเห็นบั๊กที่ตัวเองมองข้ามไปเป็นเดือน การเป็น Game Developer คือศิลปะของการประนีประนอมระหว่าง "จินตนาการ" กับ "ทรัพยากรที่มีจำกัด" ใครที่กำลังนั่งแก้บั๊กข้ามคืน หรือกำลังงมกับ Code ที่ตัวเองเขียนเมื่อวานแต่จำไม่ได้แล้ว... คุณไม่ได้สู้ดวงเดียวครับ! 👨‍💻☕️ `$$printf("Hello, World!");$$` #GameDev #LearningToCode #IndieDevTips #Nostr #SoftwareEngineering #DeveloperCommunity #siamtrs

GameDevLearningToCodeIndieDevTipsNostrSoftwareEngineeringDeveloperCommunitysiamtrssoftware developmentnostr developpementnostrdevs

Nostr-Mail Protocol White Paper

Originally written 7/31. Author Steven Day. This was the original idea that started development of nVelope

Nostrnostr developpementemailcodingDecentralization

Calendar by Formstr Release - 3rd November 2025

Formstr releases updates on calendar.

nostr developpementsoftware developmentFormstrRelease

Operation Kidstr 02: North Star

This article proposes a foundation to guide safer internet tools for children within the Nostr ecosystem. By developing relays, clients, and bunkers independently yet coherently, it creates layered protections with broader benefits for all users.

KuboChildrenParentsClientsRelaysBunkernostr developpementKidstrKubo KidsNostr

Operation Kidstr, 1: Circles and levels of trust

This second article in the series outlines “Kidstr,” a framework for building a safe online environment for children using a three-level trust system. It explains how parents can define what their children see and interact with, while introducing supporting tools like client controls, relay hygiene, and profile management.

KidstrKuboKubo KidsParentsChildrenWeb of Trustnostr developpement

Operation Kidstr, 0: A Nostr-enabled safe and suitable internet.

The first article in a series on providing parents the tools to shape a safe and suitable internet for their children. It outlines the need, motivation and reasoning behind the initiative.

KidstrKuboKubo KidsParentsChildrenWeb of Trustnostr developpement

Satoshi Scoop Weekly, 22 August 2025

🍨 Your weekly bite of the latest updates from the Bitcoin ecosystem!

Lightning NetworklightningBitcoinNostrnostr developpementweb5DecentralizationutxoBlockchain

Satoshi Scoop 周报 2025 年 8 月 22 日

🍨 不可错过的每周比特币生态深度速览

Lightning Networkweb5bitcoinlightningrgblayer2Decentralizationvibe-codingnostr developpementNostrutxo

What if?…

What if Nostr app could save a Illiterate country?

POLITICSnostr developpementnostrdevsSocial#nostrBitcoin#health#life#literature#lightning#asknostr#ZAPDEEZNUTZ 🥜⚡️

nostterに画像最適化機能つけたよ（サーバー編）

# nostterに画像最適化機能つけたよ（サーバー編） この記事は[Nostr Advent Calendar 2024](https://adventar.org/calendars/10004) の3日目の記事です。 あまり技術的な話はないので暇つぶし程度に読んでみてください。 ## どうしてこうなった？ そもそも認証の改善以前にNostrあんまり人が増えてないのが一番課題だよねと思ったのが始まりでした。 Nostrに人が増えないのはオーガニック検索流入が少ないからに違いないと特に根拠もなく思ったのでNostrのまとめサイト(Toggeter)のようなものを作ろうと考えました。 ところでNostrのまとめを行うアプリ自体は鎌倉さんという方が[ノスリ](https://nosli.vercel.app/)というのを作成されていました。ブログ形式のイベントにTwitterライクな短文投稿をまとめるというものでまさしくToggeterですが、そこまで活用されていません。 そこでその仕組みをありがたくそのまま転用してまとめ記事を何らかの方法で量産しつつ、一つのドメインのサイトにまとめてSEOもなんかうまいことやれば検索流入増えるんじゃねという目論みです。 ところでそのまとめサイトは静的サイトジェネレータで（SSG：Static Site Generator）でつくりたいなと思いました。いや普通に考えてSSRにしてサーバ側でNostrからデータとってきたらSEO的にもよくねって感じなんですが、SSRでサーバーでウェブソケット呼ぶのだる…レイテンシを考慮すると結構不利じゃないかなと思ったわけです。うそです。そこまで考えてなくてほとんど個人的な好みです。（多分ちゃんとキャッシュきかせればそんなにレイテンシ問題にならなさそうな気がする）。ただキャッシュとかも考慮すると結構複雑な気はする。 ということで今年の6月頃にNostrのブログ記事を[SSGするサイト](https://nostr-ssg-blog-template.pages.dev/)をためしに作りました。 去年のアドベントカレンダー記事とか乗っけてます。 全然画像最適化の話になりませんね。もうちょっとです。 SSGのブログといえば[Gatsby](https://www.gatsbyjs.com/docs/glossary/static-site-generator/)（今は下火かも）とかで作成した経験があります。Gatsbyでは[画像用のプラグイン](https://www.gatsbyjs.com/docs/how-to/images-and-media/using-gatsby-plugin-image/)が公式に用意されていて生成されたブログに表示される画像はもとの画像データから変換され、表示時のサイズに最適化されたサイズにリサイズすることができます。 それだけではなくサイトの初期表示時には画像の画質を落としてぼやけた画像を表示してその後元画像が読み込まれたらきれいな画像を表示する、みたいなことができます。インラインでデータを持っているのでHTMLの表示と同時に画像の初期表示ができたりします。（その頃はよくわかってなかったがNostrの[NIP-92](https://github.com/nostr-jp/nips-ja/blob/main/92.md)で定義されているblurhashとかを使っていたんでしょう多分） とにかくSSGは初期表示の速さが良い。というのが自分の頭の中にあるわけです。SSGのブログをNostrで作るとなると当然同じことがやりたい。 しかし、Nostrの画像はただのURLです。(オプショナルで画像のメタデータを定義できる[imeta](https://github.com/nostr-jp/nips-ja/blob/main/92.md)タグはあるが…) 基本的にSSGの画像最適化というのはローカルに存在する画像データをビルド時に変換するという流れで行われます。もしくはリモートURLに画像が置かれる場合は画像ストレージサービスやCDN上で配信されるときに最適化されることになります。 参考: [Svelteの画像ベストプラクティス](https://kit.svelte.jp/docs/images#loading-images-dynamically-from-a-cdn) Nostrの画像はただの外部のURLですから(2回目)、ローカルの画像を変換する方法は採用できないわけです。無理やり実行するならビルド時にURLからすべての画像を一旦ダウンロードして変換するとかも考えましたが、ただの外部URLというのはつまりは一体どういうファイルなのかダウンロードしてみるまでわからない、要するに全然信頼できないということですから、よくわからないURLをかたっぱしからダウンロードするようなことは避けたいわけですね。（極端な話100GBの画像URLとかつくって攻撃されたら破綻しますよね） ここが結構他の中央集権的なSNSと違って辛いところなのかなと思います。X（Twitter）とかであれば画像ストレージサーバは一つなので表示される画像の形式も一つに限定されるのですが、画像のアップロードが外部頼みでただのURLなので（３回目）何が来るかわからないということですね。 サーバ側で画像形式などを制限できない(imetaも信頼できるかわからない)となるとクライアント側でなんとか対応する必要があり、Nostrはクライアント側が大変なプロトコルだなあとということに思いを馳せていましたが、いろいろ考えたり調べた結果として作るべきものは画像最適化のためのプロキシサーバであるということがわかりました。 プロキシサーバというのはここでどういう働きをするのかというと、もとの画像がおいてあるサーバとクライアントのあいだに入って、もとの画像を一旦ダウンロードして圧縮したり縮小したりしてそのあとクライアントに送ってあげるという働きをします。 > プロキシがないとき `[画像置き場] -> [クライアント]` > プロキシがあるとき `[画像置き場] -> [プロキシ] -> [クライアント]` 利点としてはクライアントが実際にダウンロードするのはサイズの小さな画像になるので通信量や画像の表示スピードは改善します。が、一方でサーバを経由する分通信にかかる時間（レイテンシ）が長くなります。というわけなので、当初の目的である表示速度の改善を実現するには、画像をエッジキャッシュするなどの対応が必須となります。平たく言うと一度送った画像はプロキシで保存しておいて次に要求されたらそれをすぐ返すということです。 画像をどれくらいのサイズにするか、画質はどうするかなどはプロキシに指示してあげれば良いのでクライアント側は想定通りの画像を受け取れてハッピーということになります。嘘です。ある程度はハッピーですが、プロキシ自体がエラーを返す可能性もあるし、処理できなくてもとの画像をそのまま返す場合もあります。そんなあれこれの結果、クライアントはフォールバック処理を実装する必要がありました。（それはまた別の記事で） 一方で自分はNostrのモバイルクライアントのヘビーユーザですので、Nostrの通信量の多さも解決したい課題でした。Nostrやってるとすぐギガがなくなります。 通信量の多さのボトルネックはウェブソケットで送られるNostrのイベントの通信量というよりは投稿に添付される画像のダウンロードの方ではないかという話もTLで耳にしたため（特に裏もとらず）、いっちょ画像最適化のプロキシサーバを作ってクライアントに実装してプルリクエスト投げるかと考えました。 そこで私はまずクライアントをAmethystからnostterに乗り換えることから始めました。なぜならばAmethystよりもTypeScriptとSvelteで書かれているnostterのほうがコントリビュートしやすかったという私的な事情です。 ## 解決したい課題 遠回りしてきましたが課題はこれ。 - Nostrの画像の表示改善 - Nostrの通信量の改善 ## インターフェイス(設計) 画像最適化のプロキシは実装よりもインターフェースを考えるのが大変です。ここはとても苦労しそうな気がしたので、**何も考えず** cloudflare Imagesのインターフェースをそのまま借用することにしました。 https://developers.cloudflare.com/images/transform-images/transform-via-url/ また何かあってもcloudflare Imageに課金して乗り換えることが可能という利点もあります。 ## 実装 とにかく時間がないので手グセでかけるTypeScriptかJS。かつ課金しないで可用性を維持できる無料枠のサーバレス環境が使いたかったので [cloudflare workers](https://www.cloudflare.com/ja-jp/developer-platform/products/workers/) に目星をつけて調査したところ、[非常に素晴らしい記事](https://zenn.dev/sora_kumo/articles/wasm-image-optimization)を見つけましたのでこのwasmのライブラリをTSから呼び出して使わせていただくことにしました。 自分の実装したところはURLのパースと、キャッシュAPIの呼び出しを行って、最後にこのライブラリを叩くだけです。 ほかはクライアントキャッシュ用のヘッダーを書き換えたりとか細かいことはやっていますが全く大したことはやっておらず、サーバは非常にリーズナブルにやりたいことを実装した形になりました。 大変助かりました。 実装したものがこちらです。 https://github.com/ocknamo/nostr-image-optimizer ## 実装後の課題 このプロキシただのパブリックAPIなのでDoS攻撃に弱いです。何回もAPIをたたかれたら無料枠をすぐに超えてしまうことが容易に想像できました。 無料枠超えても使えなくなるだけで破産はしないので安心ですが、しかし対策は考える必要があります。 ### WAF WAFです。APIに対するリクエスト回数などに対する制限をIPごとにかけています。また攻撃された場合検知できれば特定のIPや地域をブラックリストに入れることも可能です。 細かいことを説明してギリギリを攻めて攻撃されても困るので細かく説明しませんが、当初は全力でDoS攻撃されても無料枠超えないくらいの感じで制限をかけていました。 しかしNostrのTLをちょっと早めに表示するとすぐにWAFに引っかかってエラーになるという状態になることもあり、結局アイコンの表示は画像最適化の対象にしない方針にするなどの影響がありました。 いろいろあって、前提が変わり、もう少し制限をゆるくしたのでアイコンの対応は今後は検討できるかもしれません。 ## まとめ 割と手抜きで作ったことがわかるかと思います。実装しててNostrへの貢献ではあるはずですが、Nostrのプロトコル(NIPsとか)全然関係ないことやってるなと思いました。 フロントについては来週書きます。 次回のアドベントカレンダーの記事は eyemono.moe さんによる[”クライアント自作を通して得られた知見まとめ”](https://adventar.org/calendars/10004)ですね！楽しみです！

nostr developpementloading