Gitea: اتحاد التنظيم والمستودعات والمستخدمين

من المحتمل أن يكون كافياً لدعم المستودعات الموحدة

kolaente تجعل ميزة الاتحاد صراحة معنى للمستخدمين. إذا كنت ترغب في مشاركة المستودعات ، يجب عليك استخدام ميزة المرآة. ولكن سيكون من الملائم جدًا لمدير المشروع إضافة مستخدمين من مثيلات git الأخرى.

انظر أيضًا # 184 (هل هذه نسخة مكررة من ذلك؟)

strk نوع من ، ولكن أعتقد أن هذا واحد يذهب أبعد من ذلك

strk نوع من. لكن هذه المشكلة تتضمن تكاملًا كاملاً لميزة الاتحاد للمؤسسة ليس فقط لطلبات السحب.

تقصد لتفويض المستخدمين عن بعد؟
كما أعتقد أنه من المفيد تقسيم "الاتحاد" في العديد من الدول الصغيرة المختلفة
الأشياء المراد تنفيذها ، أو أن التذكرة الواحدة ستصبح كبيرة جدًا.

strk أوافق على فكرة تقسيم هذا الشيء إلى العديد من التذاكر. قد تكون هذه التذكرة هي تذكرة اتحاد المستخدم ، أليس كذلك؟ لكني لا أريد المصادقة لمستخدمي الأنظمة الأساسية الأخرى. أريد القدرة على إضافة مستخدمين آخرين. سيتلقى المستخدم دعوة من مثيل Gitea الخاص بالمستخدم. سوف يصل إلى المستودع أو المنظمة من مثيله.

يتطلب منح أذونات لشخص ما في اتحاد القدرة على ذلك
تحديد هذا الشخص (عنوان عالمي). كما ذكرت owncloud أنا
فكر في استخدامات owncloud "@"كمعرف ، لكني لا أعرف ماذا
البروتوكول الذي يستخدمه لذلك. Friendica / GNUSocial وتنفيذ OStatus الأخرى
يمكن للاتحادات أيضًا استخدام "@"تعيين شيء آخر عبر
معيار Webfinger (وهو مفتوح للسماح بتحديد ملفات
البروتوكولات). مجتمع آخر (IndieWeb واحد ، انظر indieweb.org) يستخدم
عناوين الويب لتحديد الأشخاص ، حيث يتم استخدامها مع OpenID حتى الإصدار 2.0.
يستخدم OpenID الجديد (OpenID-Connect) مرة أخرى Webfinger.

أعتقد أن معيار Webfinger قد يكون حلاً جيدًا. لكنني أعتقد أنه قد يتعارض أيضًا مع البريد الإلكتروني git للمستخدم.

أين الصراع؟

بدلاً من ذلك ، ما لا يعجبني في Webfinger هو أنه يحتاج إلى التحكم فيه
جذر المجال (الذي ليس لديك مع OpenID URL).

فيما يتعلق بـ "ما هو المعيار الذي نريد اختياره" ، أريد فقط توجيهك إلى ActivityPub الذي يتم الانتهاء منه حاليًا بواسطة مجموعة عمل الاتحاد الاجتماعي لـ W3C. بعض المشاريع التي تنفذها (أو تعمل حاليًا) هي Pump.io و Mastodon و MediaGoblin.

لا يستخدمون WebFinger على الرغم من أنهم لا يحبون فكرة المسار الثابت المعروف جيدًا ، ولكن هناك أفكار حول إمكانية التشغيل البيني .

هذه الميزة ستغير قواعد اللعبة حقًا ؛ طرح keybase.io مؤخرًا بوابة مشفرة من جانب العميل ، وهذا أمر مثير للاهتمام أيضًا.

أريد فقط أن أشير إلى أن ActivityPub قد انتهى الآن.

ستؤدي إضافة دعم لـ AP إلى جعل Gitea متوافقًا مع عدد متزايد من الخوادم الموحدة ، مثل Mastodon و PeerTube و NextCloud و HubZilla ، مما يوسع نطاق وصولها إلى حد كبير ، ناهيك عن ميزة مميزة عن GitLab.
سيكون لديها أيضًا القدرة على التخلص من GitHub باعتباره استضافة الانتقال للمشاريع مفتوحة المصدر ، نظرًا لأن معظمها موجود هنا من أجل سير عمل طلب سحب المجتمع الذي ستسمح به AP بطريقة لامركزية ، وزيادة الخصوصية والقضاء على نقطة واحدة من الفشل لـ نسبة كبيرة من مجتمع البرمجيات الحرة.

على أي حال ، آمل أن يتم تنفيذ هذا ، فمن المحتمل أن يكون ثوريًا!

كما هو مذكور بالفعل في الدردشة ، فإن ActivityPub in go هو PITA لأنه من الصعب القيام به بلغة ثابتة مثل go.

تضمين التغريدة تعتبر مواصفات ActivityPub أمرًا ثقيلًا للغاية بالنسبة للوراثة ، ولكن يجب أن يكون من الممكن تصميمها في Go مع تضمين البنية ، ولكن بقدر ما أعرف ، لا يوجد شيء مثل serde في Rust (https: //docs.serde. rs / serde_json / value / index.html) ، مما يبسط الأمور كثيرًا ، ولكن هناك بعض الجهود لتنفيذ ActivityPub في Go ، والذي قد يكون بداية جيدة لأنه لا ينفذ بالفعل تحليل json-ld فحسب ، بل أيضًا يحدد المفردات الأساسية لـ ActivityStreams.

ما المضايقات المحددة التي تفكر فيها هنا؟

MatejLach مشروع آخر https://github.com/go-fed/activity

الاقتراح ذو الصلة في مستودع gogs:
https://github.com/gogs/gogs/issues/4437

في مستودع Gitlab:
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

مرحبا! ActivityPub المحرر المشارك هنا. أنا مشغول إلى حد ما في الوقت الحالي ولكن أود أن أرى هذا يحدث ... إذا كنت بحاجة إلى أسئلة ، فلا تتردد في الاتصال بي ، أو طرح السؤال في #social على irc.w3.org

من فضلك لا تتردد في التواصل معي على Mastodon لأية أسئلة / مخاوف / تعليقات حول https://github.com/go-fed/activity مكتبة التي ذكرها @ jas99 . من الواضح أن لدي مصلحة راسخة في نتيجة القرار ، ولكن يسعدني تقديم معلومات صريحة حول تجربتي في العمل في تقاطع go + ActivityPub. أتفق مع tboerger على أن تنفيذ ActivityPub أثناء التنقل هو منحدر شديد الانحدار.

ربما يمكننا إنشاء مستودع جديد باسم index وإعداد النطاق الجديد index.gitea.io للقيام بذلك؟

لماذا نحتاج إلى خادم فهرس؟ تضمين التغريدة

سيكون رائعًا إذا كان لدينا مشاريع مختلفة تناقش التنفيذ المشترك لبروتوكول ActivityPub (مثل استخدام نفس الامتداد للأفعال ، إلخ). سيمكن ذلك مستخدمي gitea و gogs و gitlab من العمل معًا بسلاسة تمامًا مثل مستخدمي العديد من منصات الوسائط الاجتماعية التي يمكن للاتحاد مناقشتها بسلاسة.

هل يمكن أن يكون هذا المكان؟ -> https://github.com/git-federation/gitpub

jaywink فكرة عظيمة!

سيكون هذا رائعا! أعتقد أن Nextcloud (/ Owncloud) هو المثال المثالي لكيفية عمل ذلك مع التنفيذ المثالي ، كما اقترح JonasFranzDEV .

باستخدام Nextcloud ، إذا كنت أرغب في مشاركة مجلد مع مستخدم في مثيل آخر ، فيمكنني القيام بذلك بسهولة وإعداد مجلد مشترك عبر كلتا الحالتين.

إذا كان بإمكاني القيام بذلك لمستودع مستضاف على مثيل Gitea الخاص بي ، فمنح مستخدم على مثيل متحد آخر حق الوصول إلى الريبو ، مع ظهور ذلك الريبو في واجهة Gitea الخاصة بهم مع القدرة الكاملة على التفاعل مع المشكلات وما إلى ذلك (مع بعض الدلالات الواضحة في واجهة المستخدم التي تمت استضافة هذا الريبو في حالة أخرى) ، سيكون ذلك رائعًا جدًا.

إن الهدف الذي تتم مناقشته لاعتماد معيار مشترك بين Gitea وغيرها من المشاريع ذاتية الاستضافة مفتوحة المصدر (مثل GitLab CE) منطقي بالتأكيد ، وسيكون أمرًا رائعًا إذا تم اعتماده للسماح بالاتحاد بين Gitea و Gogs و GitLab وما إلى ذلك. يعد الترحيل من GitHub للمشاريع الخاصة أمرًا سهلاً مع عدم فقد أي شيء حقًا ، ولكن بالنسبة للمشاريع العامة مفتوحة المصدر ، نحتاج إلى الاعتراف بفائدة كبيرة لـ GitHub هي المجتمع. لقد اكتشفت الكثير من المشاريع بالفعل على GitHub. إذا كانت هناك طريقة ما لتوحيد المشاريع الشعبية ، فإن موجز نشاط المستخدمين (أي القدرة على متابعة صديق في حالة أخرى ومتابعة نشاطهم ، والمشاريع المفضلة ، مع مراعاة إعدادات الخصوصية وما إلى ذلك) سيكون ممتازًا - إذا كان ذلك ممكنًا.

ستكون طلبات السحب الموحدة خطوة أولى رائعة نحو هذا (# 184) ، ومن المحتمل أن تكون الميزة المفقودة الأكثر أهمية في الوقت الحالي.

بعد 11 شهرًا من التعليق الأخير هنا .. أتساءل عما إذا كانت لا تزال هناك خطط قيد التنفيذ؟

عندما يكون هناك نوع من المعايير المتفق عليها أكثر من نعم

تحدث المناقشات الحالية كجزء من المشروع الذي تم التخلي عنه ، لذا تابع هناك إذا كنت تريد معرفة المزيد: https://github.com/forgefed/forgefed

كما ذكر lafriks ، بمجرد وجود معيار متفق عليه ، يمكن للمشاريع المختلفة تنفيذه.

عنوان URL الصحيح للمشروع المفقود هو الآن https://notabug.org/peers/forgefed

يبدو أن هذا يجب أن يكون ذا أهمية قصوى الآن ، مع الأخذ في الاعتبار أن Github تقوم الآن بإزالة حسابات ppl من بلدان بأكملها.

لدى ForgeFed الآن منتدى مناقشة . سيكون من الرائع إشراك شخص من Gitea.

+1 لهذا. سيكون العمل من مثيل محلي مستضاف ذاتيًا ولكن ليس معزولًا بسبب هذا الاختيار هو الأفضل حقًا في كلا العالمين.

ستحتاج مجموعة عمل ForgeFed بشدة إلى مطورين من التشكيلات الحالية لإبداء التعليقات: https://talk.feneas.org/t/working-group-instructions/196

أود فقط أن أضيف أنه قبل أن تلهم Microsoft الهجرة الجماعية بعيدًا عن Github ، لم تكن هذه ميزة قاتلة ... الآن هي كذلك. أقل وأقل من مستودعات إعادة الشراء لمشاريع نظام التشغيل التي أبحث عنها موجودة على Github الآن (MAYBE معكوسة هنا).

لقد قرأت أن تاريخ التزام Github يمكن أن يقرأ مثل السيرة الذاتية وأن أحد الأسباب التي تجعل عالم البرمجيات مهنيًا متنقلًا هو أنه يمكن لأي شخص أن يعلِّم مهاراته القيمة بنفسه ، ويظهرها بسهولة (تاريخ github العام) ، وبالتالي مؤهل للحصول على أرباح أفضل / إلخ. إذا كان سجل مساهمتك منتشرًا على العشرات من الخوادم الخاصة ، فسيكون ذلك أقل وضوحًا / مفيدًا.

أيضًا ، يمكن أن يتعطل أي من هذه الخوادم في أي وقت وذهب هذا الجزء من سجلك الآن. يعني التنفيذ المناسب للمستودعات الاتحادية أنه يمكنني المشاركة في عشرات المشاريع في عشرات الحالات (من المثال الخاص بي) وإذا تعثرت جميعًا ، فسيظل لديّ "ملف تعريف git الموحد" الخاص بي.

الارتباط بخريطة طريق ForgeFed (يوجد تمويل لأولئك الذين سيعملون عليها):

https://notabug.org/peers/forgefed/issues/87

ربما ، من أجل تنفيذ بسيط ، يمكن لـ gitea تشغيل عقدة ipfs في الخلفية التي تستضيف ملفات المستودعات المحلية (باستخدام ipns للإشارة إلى أحدث إصدارات المستودعات). يمكننا بعد ذلك تطبيق بروتوكول ثرثرة بسيط للعثور على مثيلات gitea الأخرى والحصول على تجزئات ipns والبيانات الأولية (النجوم والاسم).
ستكون فائدة استخدام ipfs عندما يرغب المستخدمون في مثيل واحد في عرض مستودعات أو تفرعها في مثيلات أخرى ، فسيساهم ذلك في استضافة أجزاء من هذا المستودع ويجعل الوصول إلى المستودع أسرع للشبكة ككل.

يمكن أيضًا استخدام استخدام ipfs / ipns لتوزيع بيانات المستخدم مثل المستودعات المميزة بنجمة وطلبات السحب والسيرة الذاتية وما إلى ذلك ، ستخزن كل عقدة الأسماء وتجزئة ipns فقط للمستخدمين على الشبكات الأخرى التي يهتم بها المثيل وسيكون من التافه طلبها بيانات الملف الشخصي للمستخدمين غير المعروفين.

يحتوي ipfs بالفعل على تطبيق go وعلى سبيل المثال يمكن استخدام اكتشاف شيء كهذا .

لا توجد متطلبات للتخزين من نظير إلى نظير هنا ، وما تصفه لا يبدو مطلوبًا أو حتى مرتبطًا بالمشكلة المطروحة. لا أعتقد أن هناك اهتمامًا بالابتعاد عن تنسيق تخزين Git وبروتوكول النقل. ربما يجب أن تفتح مشكلة منفصلة إذا رأيت فائدة هنا (أنا بالتأكيد لا أفعل ذلك).

لا توجد متطلبات للتخزين من نظير إلى نظير هنا

أعتقد أن gitea ستستفيد بشكل كبير من مشاركة المستودعات من نظير إلى نظير بحيث تكون عمليات إعادة الشراء الشائعة زائدة عن الحاجة في حالة انخفاض الحالات. في حين أن شخصًا ما يمكنه فقط عكس المستودع إلى مثيله الخاص ، إلا أنه سيؤدي إلى تجزئة تطوير المشروع إذا لم يكن هناك مكان مركزي للالتزام به. إذا تم وضع بروتوكول git في طبقات IPFS ، فإنه سيسمح بإلغاء المضاعفة عند تفرغ المشاريع على مثيل واحد (لذلك لن يتم تخزين نسخة كاملة).

ما تصفه لا يبدو مطلوبًا أو حتى متعلقًا بالمشكلة المطروحة.

السبب في أن الاتحاد مفيد جدًا (ولماذا يريده الناس كثيرًا) هو أنه يسمح بالتعاون عبر المثيلات. يحتوي نظام الاسم بين الكواكب (IPNS) على سلوك مماثل لـ OpenID لأنه يمكن استخدامه لتحديد مستخدم لديه إذن لتحديث بيانات معينة (مثل مستودعاتهم وملفهم الشخصي). يمكن أن يحدد عنوان IPNS بشكل فريد مستخدمًا من مثيل آخر دون الحاجة بالضرورة إلى ربط هذا المستخدم بمثيل معين. دعنا نعطي مثالا:
تستضيف أليس ذاتيًا مثيلًا من gitea في aliceland.net
عندما تنشئ أليس حسابًا جديدًا ، ستنشئ gitea ملفًا شخصيًا فارغًا ، وتستضيفه على IPFS ، ثم تنشئ عنوان IPNS فريدًا يشير إلى هذا الملف الشخصي. عندما تنشئ أليس مستودعًا جديدًا أو تقوم بتحديث ملفها الشخصي بأي شكل من الأشكال ، ستقوم gitea (خلف الكواليس) بإنشاء سجل IPFS جديد ، وإلغاء تثبيت السجل القديم ، وإعادة تعيين عنوان IPNS الخاص بـ Alice إليه.
لنفترض الآن أن بوب يريد إرسال طلب دمج من المرآة الخاصة به للمستودع على bobland.net إلى aliceland.net.
عندما قام بوب في الأصل بتقسيم repo الخاص بـ Alice إلى bobland.net ، فقد قام بتدوين IPNS الخاص بمستودع Alice بالإضافة إلى موقع IPFS للالتزام الذي تفرع منه.
عندما يريد بوب فتح طلب دمج ، يكتب رسالته ثم يضع bobland.net الأشياء التالية في كتلة IPFS:

• عنوان مستخدم IPNS الخاص بـ Bob
• عنوان IPFS للالتزامات التي يريد بوب سحبها
• عنوان IPFS للالتزام في مستودع Alice الذي يجب تعديله
• رسالة بوب وعنوان طلب الدمج
• توقيع البيانات باستخدام مفتاح ملف تعريف IPNS الخاص ببوب

سيقوم Bobland.net بعد ذلك بإرسال عنوان IPFS إلى aliceland.net والذي يمكنه بعد ذلك اختيار تجاهله تمامًا ، أو تحليل العنوان ، والتحقق من الالتزامات ، وإنشاء عنوان IPNS لسلسلة التعليقات (التي تشير إلى جميع التعليقات) ثم إخطار أليس أن شخصًا ما اسمه بوب في حالة Bobland.net قد أرسل طلب دمج لـ 3 عمليات عبر IPFS. سيتم أيضًا استضافة التعليقات عبر IPFS ويمكن الوصول إليها عبر عنوان IPNS.
يمكن تطبيق هذا النمط من استخدام IPNS للبيانات القابلة للتغيير (مثل سلسلة التعليقات) و IPFS للبيانات غير القابلة للتغيير (مثل التعليقات والالتزامات) لمعظم الاتحاد بين المثيلات.

لا أعتقد أن هناك اهتمامًا بالابتعاد عن تنسيق تخزين Git وبروتوكول النقل.

لن يضطر هذا النهج في الاتحاد إلى الابتعاد عن تنسيق Git. يمكن ببساطة وضع Git في طبقات وتخزينها على ifps (مع الاستفادة أيضًا من إلغاء البيانات المكررة). ليس بالضرورة أن يتكامل نظام Merkle Tree من Git مع IPFS (على الرغم من أن ذلك سيكون رائعًا) وسيظل بروتوكول نقل git كما هو ، فإن IPFS سيعدل الاتصال بين الحالات.

هل يمكنك فقط فتح قضية منفصلة؟ هذا يتعلق بشيء محدد ، وتعمل ForgeFed بالفعل على بروتوكول. والأفضل من ذلك ، طرحه معهم.

يبدو تراكم المشكلات المتعلقة بالتعليقات مثل "ماذا عن ipfs / filecoin / blockchain" أمرًا وقحًا.

+1

يناقش GitLab هذه الميزة أيضًا: https://gitlab.com/gitlab-org/gitlab/-/issues/6468

لقد تعرضت لضغوط من gitea dev discord منذ بضعة أيام بصفتي FYI ، وكنت أحاول بشكل استباقي الوصول إلى بعض الأشخاص الذين يقفون وراء ForgeFed ، كما هو الحال مع go-fed v1 الذي يتم تنفيذه وتوثيقه ، سيكون من الجيد الحصول على مثيل من gitea المتحدة على ActivityPub على الرغم من أنه ليس مجهودًا بسيطًا. أعتقد أن الناس gitea مشغولون مع أولويات أخرى أجهزة الصراف الآلي. لسوء الحظ ، لم أحقق نجاحًا في الحصول على أي من أفراد ForgeFed. :(

بعضنا في مجتمع ActivityPub ، الذي خرج من APConf2020 ، يختبر وجود عملية توثيق خفيفة الوزن على مستوى القاعدة الشعبية على مثيل gitea ، ومن الغريب عدم القدرة على الاتحاد معها حتى الآن.

يحتوي Git بالفعل على جميع الميزات اللازمة للانعكاس اللامركزي ، والوظيفة الوحيدة المفقودة هي ما هو ضروري لتنسيقها ، وهو بالضبط ما يفعله ForgeFed. ليس هناك حاجة إلى أن يكون IPFS هنا ، وبالنظر إلى الكارثة التي مر بها إطلاق شبكتهم الرئيسية ، فأنا لست متأكدًا من أنه من الآمن الارتباط بشدة بالمشاريع الأخرى بواسطة Protocol Labs.

أنا مهتم بالتعاون في أي من المبادرات الحالية. دعنا نحاول تشكيل مجموعة عمل معًا. يمكن أن تقترح قناة Matrix هذه لمزيد من المناقشة #n تستحق: tincan.community