COMPΞZ 🧬

من فکر نمی‌کنم فارکستر هیچ‌وقت واقعاً بمیرد. شرکت‌ها ممکن است شکست بخورند. تیم‌ها ممکن است مسیرشان را عوض کنند. کلاینت‌ها ممکن است ناپدید شوند. سیاست‌ها ممکن است محدودکننده‌تر شوند. حتی جامعه‌ها هم ممکن است از هم جدا شوند. اما یک پروتکل باز فرق دارد. اگر یک مسیر دیگر برایت مناسب نباشد، می‌توانی یک کلاینت دیگر بسازی. اگر یک جامعه دیگر نماینده‌ی تو نباشد، می‌توانی جامعه‌ی جدید خودت را شکل بدهی. اگر یک مجموعه قانون دیگر قابل قبول نباشد، می‌توانی انشعاب بگیری، آزمایش کنی و مسیر متفاوتی را ادامه بدهی. قدرت واقعی یک پروتکل باز همین است: هیچ شرکت، تیم یا اپلیکیشنی نمی‌تواند برای همیشه شکل نهایی آن را تعیین کند. تا وقتی آدم‌هایی باشند که حاضرند بسازند، زیرساخت اجرا کنند، کلاینت توسعه بدهند و دور آن جامعه شکل بدهند، فارکستر می‌تواند به تکاملش ادامه بدهد. برای همین من معتقدم فارکستر به سادگی «نمی‌میرد». انشعاب می‌گیرد. خودش را تطبیق می‌دهد. دست‌به‌دست می‌شود. و به چیز تازه‌ای تبدیل می‌شود. پروتکل‌ها زنده می‌مانند، چون آدم‌ها می‌توانند یک مسیر را ترک کنند بدون اینکه خود پروتکل را ترک کنند. https://farcaster.xyz/compez.eth/0x2824333a

کلاینت فعلی فارکستر این مسائل کاربری رو هم داره: ۱) کاربر ایرانی باید دغدغهٔ اینو داشته باشه که هر لحظه ممکنه بن بشه! ۲) کاربر ایرانی نمی‌تونه با زبون بومی خودش درون فارکستر فعالیت کنه، نمی‌تونه فارسی بنویسه و اگر هم بنویسه ممکنه از خیلی از ویژگی‌های کلاینت محروم بشه. چطور که من نوشتم بارها هم نوشتم و به طور کامل از تمام مزایای فارکستر محروم شدم. ۳) کاربر ایرانی نمی‌تونه روی شبکهٔ غیرمتمرکز فعال بمونه بدون مگر اینکه VPN به خاطر احراز هویت روشن کنه. می‌دونید که خیلی از حساب‌ها به خاطر همین ایرانی بودن به باد رفتن؛ چون کلاینت فارکستر یک کلاینت آمریکاییه و شمارو خیلی راحت می‌تونه بن کنه. ۴) محیط فارکستر مناسب برای محتوای فارسی نیست؛ همه صرفاً برای پشتیبانی از زبان‌های لاتین طراحی شده. ۵) کیف پول فارکستر عملاً در انحصار خود شرکت آمریکایی هست و می‌تونه اجازهٔ استفاده از اون رو به کاربر ایرانی نده. ۶) پیام‌ها، چت‌ها و در کل گفتگو‌های درون فارکستر محدود به سبک خود فارکستره؛ هیچ انتظاری نیست که تجربهٔ مشابه تلگرام رو ازش داشته باشیم. ۷) نود‌های فعلی فارکستر نمی‌تونن مسدود کردن و اعمال محدودیت به IP‌های ایرانی رو نادیده بگیرن در اکثر موارد خیلی راحت با تنظیم چند تا سیاست‌ دسترسی روی کلاد‌فلیر می‌تونن محدودیت شدیدی ایجاد کنن. ۸) کاربران ایرانی اگه می‌خوان بخشی از توسعه‌دهنده‌های فارکستر باشن یا اپلیکیشن یا برنامه‌ای رو درونش منتشر کنن؛ باید طبق قوائد و سیاست‌های شرکت آمریکایی پیش برن؛ اصولاً در صورتی که بدونن ایرانی هستید تحریمید. و ده‌ها مورد دیگه که می‌تونم فهرستش کنم... این‌ها دلایلی هستن که جنی‌کستر باید ساخته بشه. تمام! 👋🏼

پس باور کنید، یا نکنید حقیقت پنهان پشت همهٔ این ابزار‌های چند سکویی مثل Xamarin، React Native یا Flutter و گزینه‌های دیگه که طرفدار‌های زیادی دارن اینه که فقط سطح بالا هستن نیاز به دانش خیلی حرفه‌ای ندارد. واسه همین افراد زیادی میرن دنبالش. اما این دلیل بر بهتر بودنشون نیست چون خروجیشون به شدت مزخرفه! 😉 خب به هر حال نمی‌شه که هم خدارو بخوای هم خرمارو... یه چیزی از دست میدی در ازای اون راحتی و سادگیش. هیچ چیز ساده‌ای لزوماً خوب نیست؛ بعضی جاها سخت رو انتخاب کن ولی خروجیش یه چیز دیگست. 👌 الآن منبع کد فارکستر متن‌باز شده! همهٔ توسعه‌دهنده‌ها رفتن همون کد نوشته شده با ری‌اکت رو شاخ و برگ بدن! خب این یعنی همهٔ مسائل گذشته مثل کندی، لگ‌ها، مصرف بیش‌از حد انرژی و ... همشون سرجاشون باقی خواهد ماند و فقط یه سری ویژگی‌ها بهش اضافه خواهند کرد. منتظرم ببینم خروجی چیز‌هایی که می‌سازن چقدر متفاوت خواهد بود :) و چقدر تفاوت بین چیزی که من می‌سازم با اون‌ها وجود خواهد داشت. سخت نیست یک VS بین Genycaster که با سی++ می‌سازمش با Farcaster کلاینت‌هایی که با ری‌اکت باز سازی خواهد کرد. 😌 ببینیم کدومش در چه حد روان، سریع، مطمئن و خفن خواهد شد. 😏

یه چیزی در مورد Qt هست که دوست دارم روش تأکید کنم. نرم‌افزار فعلی فارکستر رو با React Native نوشتن و خب، نتیجه‌ش رو همه دیدیم؛ مصرف منابع بالا، سرعت پایین، لگ و تأخیر توی رابط کاربری و در کل تجربه‌ای که واقعاً از یه کلاینت درست‌وحسابی انتظار نداری. چیزی که من توی Qt خیلی دوست دارم اینه که «چندسکویی بودن» براش فقط یه شعار تبلیغاتی نیست، یک چند سکویی واقعیه! کد نویسی باهاش به مراتب نسبت به ری‌اکت و امثالش سخته چون اون‌ها در سطح وب قرار می‌گیرن و کیوت در سطح سیستم‌عامل. کیوت نیومده یه محیط وب رو بچپونه توی برنامه و اسمش رو بذاره اپلیکیشن چندسکویی. نیومده برای هر کاری هم یه عالمه پل و واسطه بین کد شما و سیستم‌عامل بسازه. یعنی شبکه، فایل، نخ‌ها، پنجره، ورودی، گرافیک، دیتابیس، ذخیره‌سازی امن، اعلان‌ها، زمان‌بندی‌ها و کلی چیز دیگه رو یه بار می‌نویسی و Qt خودش دردسر تفاوت‌های macOS، Windows، Linux، Android، iOS و بقیه‌ٔ سکوها رو جمع می‌کنه. هر جا هم لازم باشه، مستقیم میره سراغ امکانات بومی همون سیستم‌عامل و الکی شبیه‌سازی نمی‌کنه. چند سکویی واقعی یعنی نه تنها لازم نیست برای هر سیستم‌عامل دوباره همون منطق رو از اول بنویسی، مهم‌تر از اون نباید کدی که می‌نویسی من در آوردی یا در یک لایهٔ بالاتری قرار بگیره. یه هسته‌ٔ واقعی CPP داری که واقعاً روی چند سیستم‌عامل کار می‌کنه. فرقش برای من دقیقاً همینه که می‌گم: کیوت چندسکویی بودن رو شبیه‌سازی نمی‌کنه! واقعاً برای توسعه‌ٔ چندسکویی ساخته شده. وقتی با کیوت کد نویسی می‌کنم، حس نمی‌کنم دارم یه نسخه‌ٔ ضعیف‌تر از برنامه‌ٔ بومی می‌سازم که فقط بتونم بگم «خب، روی چندتا سیستم‌عامل اجرا میشه!» این هدف چرنده! هدف اینه که یه نرم‌افزار واقعی داشته باشیم؛ سریع، کم‌مصرف، تمیز و قابل نگهداری، با یه هسته‌ٔ مشترک که روی همه‌ٔ سکوها کار کنه نه اینکه یه چیزی سر هم کنی با چهارتا فناوری وب بسازی بگی ساختمش! اونا پاستیل‌های نرم‌افزاری هستن نه یک محصول واقعی.

یکی از انتخاب‌های خوب در بازنویسی کلاینت فارکستر با ++C و Qt، استفاده از QtKeychain است. داشتم راجع به احراز هویت چند سیستم‌عاملی فکر می‌کردم که چطور پیادش کنم رسیدم به QtKeychain! به ‌جای اینکه برای هر سیستم‌عامل جداگانه لایه‌ٔ ذخیره‌سازی امن credentialها را از صفر پیاده‌سازی کنیم، QtKeychain یک انتزاع تمیز و cross-platform در اختیارمان می‌گذارد. یعنی یک API مشترک، اما با استفاده از مکانیزم امن بومی هر پلتفرم و نتیجش می‌شه: • کد بسیار کمتر • حذف بخش بزرگی از پیاده‌سازی‌های اختصاصی سیستم‌عامل • نگهداری ساده‌تر • سطح خطای کمتر • هماهنگ‌سازی‌های تمیزتر با macOS، Windows و Linux • و مهم‌تر از همه، نگهداری امن توکن‌ها و احراز هویت حساس این دقیقاً همان چیزی است که از یک وابستگی خوب در سیستم انتظار داریم:

small abstraction, big reduction in complexity.

#Qt #QtKeychain #CPlusPlus #CrossPlatform

وووییییی! وووی وی وی وی ویییی! منِ سی++ کار مغزم سوت کشید. 😄

اولین تراکنش Quantum-Safe روی Bitcoin Mainnet انجام شد. ✅ این یعنی یک روش واقعی برای محافظت از تراکنش‌ها در برابر تهدید آینده‌ٔ کامپیوترهای کوانتومی روی شبکه اصلی آزمایش شده است. این روش با نام QSB — Quantum-Safe Bitcoin توسط تیم StarkWare توسعه داده شده و نکته‌ٔ جالبش این است که:

بدون Hard Fork، بدون Soft Fork و بدون تغییر Consensus بیت‌کوین کار می‌کند.

مشکل اصلی بیت‌کوین در برابر کوانتوم بیشتر مربوط به امضاهای ECDSA/Schnorr و secp256k1 است؛ چون یک کامپیوتر کوانتومی قدرتمند می‌تواند در آینده با الگوریتم Shor امنیت ECC را تهدید کند. و QSB بخشی از امنیت را به ساختارهای Hash-based منتقل می‌کند و برای پیدا کردن مقادیر معتبر، فضای بسیار بزرگی را روی GPU جستجو می‌کند. هسته‌ٔ سنگین پروژه با CUDA CPP نوشته شده و عملیات‌هایی مثل: SHA-256 RIPEMD-160 secp256k1 arithmetic DER validation را با سرعت بسیار بالا انجام می‌دهد. در RTX PRO 6000 حدود 238 میلیون candidate در ثانیه گزارش شده است. #Bitcoin #Quantum #Security #بیت‌کوین #کوآنتوم

فصل بعدی شما… باعث می‌شود برخی افراد آرزو کنند که کاش با شما بهتر رفتار می‌کردند.

در به‌روز رسانی‌های جدید هایپر اسنپ از فارکستر می‌تونه گزینهٔ خوبی به عنوان جایگزین پروتکل پایه باشه. با این پروتکل ما می‌تونیم نرم‌افزار بومی رو بازسازی کنیم بدون اینکه هزینهٔ سربار و باز نویسی پروتکل خامِ فارکستر رو متحمل بشیم. شروع خوبیه! 👌قبلاً هم گفته بودم نود ایرانی رو پیاده می‌کنم اما قبل از این کار ظاهراً خود اپلیکیشن رو قراره بدون نود ایرانی اجرا کنیم و بعد از آزمایش‌های اولیه داخل کشور هم نودش رو راه‌اندازی کنیم. بحران فارستر داره تبدیل میشه به یک چیز بسیار تمیز‌تر!

راهی هست که کانال تلگرامی رو به مدت مشخصی کلاً ببندیم؟ طوری که بعداً بتونم بازش کنم؟

صبح تا شب کارمون شده مودم تنظیم کردن، VPN تنظیم کردن، اینترنت رو درست کردن برای چند لحظه فقط که بین هر کامیت و پستی هم که میزنم صد بار قطع میشم بماند حالا حجم دزدی هم می‌کنید... بایت به بایت هر پولی که به شماها میدم درد بشه بچسبه خر خرهٔ زن و بچتون و طرفدارای لجنتون صد پدرای کثافت... این چه وضعشه حروم‌خورای بی شرف! دیگه از این بدتر چی باید باشه بی‌همه چیز؟ این چه زندگیه این حروم لقمه!!؟ برید دعا کنید که قدرت همینطور دست شما بمونه! برید دعا کنید که واقعاً ابر قدرت دنیا بشید! فقط دعا کنید روزی پنج مرتبه هم نماز بخونید از طرفداراتونم بخواین همه باهم نماز دست جمعی بخونید که دست به قدرت بمونید عوضیای کثافت... بی‌همه چیزای دزد غارت‌گر. اسمشونم گذاشتن مسلمون... ما مسلمونیم! شما هیچ پوخی نیستید جز بی‌شرف‌ترین بی‌دین‌ترین، بی‌خرد‌ترین، بی‌احساس‌ترین، بی‌رحم‌ترین، بی‌عرضه‌ترین موجودات روی زمین که خدا شمارو آفریده که بشریت به عنوان آیندهٔ شیطان بهشون نگاه کنه درس عبرت بگیره. بی‌همه‌چیزای بی‌ناموس.

در مورد عناوین زیر هم بدونید بد نیست، بعضی اوقات دیدین که می‌گن فلان بازی یا برنامه rewrite یا remake یا ریبوت شد! اینا معنا و تعریف دارن. • بازنویسی Rewrite یعنی همان محصول را از نو با کد/فناوری جدید بنویسی. رفتار و ساختار کلی می‌تواند تقریباً همان بماند. مثلاً Farcaster client را از TypeScript به ++C منتقل کنی، بدون اینکه فلسفهٔ محصول خیلی عوض شود. • باز سازی Refactor یعنی کد موجود را تمیزتر و بهتر کنی، بدون اینکه محصول را از نو بسازی. • انتقال Port یعنی همان نرم‌افزار را برای پلتفرم یا تکنولوژی دیگری تطبیق بدهی؛ مثلاً نسخهٔ فعلی موبایل را برای دسکتاپ از همان کلاینت (بدون باز‌نویسی) با همان فناوری و زبان. • بازسازی Remake یعنی محصول را دوباره بسازی، اما با آزادی زیاد برای تغییر معماری، UI، performance model و حتی بعضی رفتارها. ایده و هویت اصلی باقی می‌ماند، ولی implementation می‌تواند کاملاً جدید باشد. • راه‌اندازی مجدد Reboot یعنی «شروع دوبارهٔ پروژه با یک دیدگاه جدید». معمولاً فقط کد عوض نمی‌شود، بلکه direction، architecture و تجربهٔ محصول هم بازتعریف می‌شود.

در مورد عناوین زیر هم بدونید بد نیست، بعضی اوقات دیدین که می‌گن فلان بازی یا برنامه rewite یا remake یا ریبوت شد! اینا معنا و تعریف دارن. • بازنویسی Rewrite یعنی همان محصول را از نو با کد/فناوری جدید بنویسی. رفتار و ساختار کلی می‌تواند تقریباً همان بماند. مثلاً Farcaster client را از TypeScript به ++C منتقل کنی، بدون اینکه فلسفهٔ محصول خیلی عوض شود. • باز سازی Refactor یعنی کد موجود را تمیزتر و بهتر کنی، بدون اینکه محصول را از نو بسازی. • انتقال Port یعنی همان نرم‌افزار را برای پلتفرم یا تکنولوژی دیگری تطبیق بدهی؛ مثلاً نسخهٔ فعلی موبایل را برای دسکتاپ از همان کلاینت (بدون باز‌نویسی) با همان فناوری و زبان. • بازسازی Remake یعنی محصول را دوباره بسازی، اما با آزادی زیاد برای تغییر معماری، UI، performance model و حتی بعضی رفتارها. ایده و هویت اصلی باقی می‌ماند، ولی implementation می‌تواند کاملاً جدید باشد. • راه‌اندازی مجدد Reboot یعنی «شروع دوبارهٔ پروژه با یک دیدگاه جدید». معمولاً فقط کد عوض نمی‌شود، بلکه direction، architecture و تجربهٔ محصول هم بازتعریف می‌شود.

از نظر تصمیم‌های استارتاپی اینکه یک برنامه رو سریع به MVP برسونن خیلی مهمه پس اشکالی نداره حتی روی موبایل با TS یا JS سر همش کنی! اما همه دیدیم و شاهد بودیم که فارکستر از نظر عملکرد سمت کاربر اصلا قابل مقایسه با تلگرام نبود و نیست. دلیلش بخث معماری و زیرساخت‌های فنیش هست، مواردی مثل تلگرام عملا کدشون بومی هست، یعنی دستورالعمل‌های نهایی کدش تبدیل می‌شه به زبان ماشین. به خاطر همین، هم سریع هست، هم روان هست و هم بسیار ایمن و با حداقل دسترسی به اینترنت خیلی روان کار می‌کنه چون معماری بومی و درستی داره. تفاوت کلاینت فارکستر این بود که سریع خواسته بودن یه چیزی رو سر‌هم کنن که بگن خب اینم کلاینت ما! به خاطر کندی و مشکلاتی که داشت حدس می‌زدم از یه سری فناوری‌های وب استفاده کردن نه بومی! امروز با انتشار کد‌هاش مطمئن شدم که درست حدس زده بودم. این بد نیست ولی برای اینکه بتونه واقعا تجربه خوبی ارائه کنه باید منعطف و سریع باشه.

علاوه بر این که مثل تلگرام از نظر تکنیکی و فنی Native و GPU-Driven می‌شه، بلکه مزایای زیادی می‌تونه داشته باشه! فرض کن فارکستر با پشتیبانی کامل از فارسی! و کلی چیز‌های دیگر. متن‌باز کردنش برای نجات دادنش تصمیم خوبی بود، خوشم اومد! 👌🏼 قبل از این هم گفته بودم نود ایرانی براش راه‌اندازی می‌کنم، حالا جدی‌تر رفت تو برنامه‌هام که کلاینتش ریبوت کامل بشه.

ساخته شده بدونیدش! ✌🏼 منتظر همین لحظه بودم😎 این تصمیم بسیار خوبی از سمت تیم بود.

نمونه فعلی خودشون با TypeScript هست! حتی برای موبایل هم از TS استفاده کردن! یکی از دلایل به شدت کند بودن فارکستر همینه که هیچ وقت به گرد پای تلگرام نرسید که نرسید! فکرشو بکن اینو Remake کنم از بیخ با ++C 🙂 چه می‌شود!؟

خب! می‌بینم که سورس کد‌های کلاینت فارکستر هم منتشر شد! حالا می‌شه یه چیز بهترشو ساخت! 👌🏼