أعتقد أن أهم كلمة في Dusk Connect هي "discover".
لقد أتاح Dusk Network SDK في إصدار تجريبي للمطورين بحيث يمكن لتطبيق dApp يعمل في المتصفح العثور على محافظ متوافقة وطلب الوصول إلى الملف الشخصي وتتبع الشبكة المحددة وإرسال معاملات يوافق عليها المستخدم. وهو يتبع نمط مزوّد مشترك بدلًا من تضمين إضافة واحدة بشكل مباشر.
يبدو ذلك كتهيئة للبنية الأمامية. أعتقد أنها قرار على مستوى النظام البيئي.
عندما تُدمج كل تطبيقات من محفظة واحدة مباشرة، تصبح تلك المحفظة بوابة غير رسمية. يمكن لمحفظة منافسة أن تدعم البروتوكول مع البقاء غير مرئية للمستخدمين، لأن كل dApp يحتاج إلى عمل مخصص. ينقل Dusk Connect هذا الاختيار إلى طبقة الاكتشاف. يطلب التطبيق تحديد أي المزوّدين متاحون، ثم يختار المستخدم.
إن الـ SDK مستقل عن الأطر، ومُهيّأ بالأنواع، ولا توجد له تبعيات وقت تشغيل. تُقلل هذه التفاصيل من احتكاك التكامل. لكنها لا تضمن أن محفظتين تفسّران الأذونات والعناوين المحمية والتواقيعات وتغييرات الشبكة بالطريقة نفسها تمامًا.
لهذا السبب تهمني اختبارات التوافق أكثر من زر اتصال مصقول.
يمكن لـ Dusk نشر واجهة مشتركة، لكن تصبح الواجهة معيارًا فقط عندما تُنفّذها محافظ مستقلة بشكل متسق. قد يؤدي المزوّد الذي يتصل بنجاح ثم يتعامل مع تغييرات الملف الشخصي بشكل مختلف إلى إخفاقات تبدو وكأنها أخطاء في التطبيق.
أنا أراقب ثلاث إشارات: ظهور محفظة ثانية جاهزة للإنتاج عبر نفس التدفق، ونتائج توافق عامة عبر الطرق الأساسية، و dApps التي تبدّل المزوّدين دون فروع مخصصة.
إذا ظهرت هذه الأمور، فسيكون لدى Dusk Connect أكثر من مجرد تبسيط وصول المحافظ. سيكون قد فصل طبقة تطبيق Dusk عن الاعتماد على تنفيذ محفظة واحدة.
الاختبار الحقيقي ليس ما إذا كانت محفظة الجهة الأولى تتصل. الاختبار هو ما إذا كانت المحفظة التالية تستطيع الوصول دون مطالبة كل مطور Dusk بالحصول على إذن.
#dusk $DUSK @Dusk
لقد أتاح Dusk Network SDK في إصدار تجريبي للمطورين بحيث يمكن لتطبيق dApp يعمل في المتصفح العثور على محافظ متوافقة وطلب الوصول إلى الملف الشخصي وتتبع الشبكة المحددة وإرسال معاملات يوافق عليها المستخدم. وهو يتبع نمط مزوّد مشترك بدلًا من تضمين إضافة واحدة بشكل مباشر.
يبدو ذلك كتهيئة للبنية الأمامية. أعتقد أنها قرار على مستوى النظام البيئي.
عندما تُدمج كل تطبيقات من محفظة واحدة مباشرة، تصبح تلك المحفظة بوابة غير رسمية. يمكن لمحفظة منافسة أن تدعم البروتوكول مع البقاء غير مرئية للمستخدمين، لأن كل dApp يحتاج إلى عمل مخصص. ينقل Dusk Connect هذا الاختيار إلى طبقة الاكتشاف. يطلب التطبيق تحديد أي المزوّدين متاحون، ثم يختار المستخدم.
إن الـ SDK مستقل عن الأطر، ومُهيّأ بالأنواع، ولا توجد له تبعيات وقت تشغيل. تُقلل هذه التفاصيل من احتكاك التكامل. لكنها لا تضمن أن محفظتين تفسّران الأذونات والعناوين المحمية والتواقيعات وتغييرات الشبكة بالطريقة نفسها تمامًا.
لهذا السبب تهمني اختبارات التوافق أكثر من زر اتصال مصقول.
يمكن لـ Dusk نشر واجهة مشتركة، لكن تصبح الواجهة معيارًا فقط عندما تُنفّذها محافظ مستقلة بشكل متسق. قد يؤدي المزوّد الذي يتصل بنجاح ثم يتعامل مع تغييرات الملف الشخصي بشكل مختلف إلى إخفاقات تبدو وكأنها أخطاء في التطبيق.
أنا أراقب ثلاث إشارات: ظهور محفظة ثانية جاهزة للإنتاج عبر نفس التدفق، ونتائج توافق عامة عبر الطرق الأساسية، و dApps التي تبدّل المزوّدين دون فروع مخصصة.
إذا ظهرت هذه الأمور، فسيكون لدى Dusk Connect أكثر من مجرد تبسيط وصول المحافظ. سيكون قد فصل طبقة تطبيق Dusk عن الاعتماد على تنفيذ محفظة واحدة.
الاختبار الحقيقي ليس ما إذا كانت محفظة الجهة الأولى تتصل. الاختبار هو ما إذا كانت المحفظة التالية تستطيع الوصول دون مطالبة كل مطور Dusk بالحصول على إذن.
#dusk $DUSK @Dusk
