لدي عدد من المجتمعات الصغيرة التي تعمل حاليًا مع دردشات سيجنال للتعاون الداخلي (وهو ما لا يتوسع على الإطلاق، هذا واضح …). أريد ترحيلها إلى ديسكورس، لذا سيكون أي نوع من الاتصال بين كلا المنصتين مفيدًا جدًا - على الأقل حتى يتم الانتهاء من الترحيل …
بعض الخلفية:
تعد محادثات Signal شائعة جدًا في ألمانيا بين المجتمعات التي لا ترغب في استخدام مجموعات Facebook أو Whatsapp أو أدوات تجارية مثل Slack أو Threema (Threema – Highly Secure Communication For Individuals and Companies – Threema). أحد الأسباب (على الأقل بالنسبة لأدوات META و Slack) هو مخاوف الخصوصية.
غالبًا ما تستخدم هذه المجتمعات محادثات Signal للتواصل الجماعي بدلاً من ذلك. لكنهم يدركون أيضًا أن هذا النوع من الاتصال غير المنظم “قصير الأجل” ليس الحل المناسب للتعاون الجماعي “الجاد” عندما يكون لديك مجموعة تضم أكثر من 20 شخصًا …
إذا كان من الممكن نسخ الإشعارات من Signal إلى سلسلة مناقشة بطريقة ما، فسيدعم ذلك إما انتقالًا سلسًا من Signal إلى Discourse أو نوعًا من التشغيل المتوازي. في المجمل، سيجعل ذلك الانتقال إلى Discourse أسهل ويخلق المزيد من قبول المستخدم.
@Thomas_Rother هل تواصلت مع المجموعة غير الربحية التي تدير سيجنال بشأن التكامل؟ أنا مهتم بالمفهوم لنفس الأسباب، ولا أريد تكرار الجهود إذا كنت قد اتصلت بهم بالفعل. ومع ذلك، ما زلت بحاجة إلى بحث أعمق في إضافة تشفير Discourse، وكذلك الحالة الحالية لتطبيق Discourse للهاتف، والذي بدا دائمًا وكأنه طريقة معقدة لإطلاق اختصار رابط.
@Muiren لم أتصل بأي شخص من جانب سيجنال بعد، على سبيل المثال، من مجتمع مطوري https://signal.org.
فيما يتعلق بالحل التقني، لا أعرف حتى ما إذا كانت هناك أي واجهات برمجة تطبيقات يمكن استخدامها لـ “عكس” محادثة جماعية في سيجنال إلى موضوع في ديسكورس، على سبيل المثال. تم بناء سيجنال في المقام الأول للاتصالات الخاصة، والمحادثة الجماعية ليست حالة الاستخدام الرئيسية، على الرغم من أنها غالبًا ما “يسيء استخدامها” للاتصالات الجماعية هنا في ألمانيا …
نظرًا لأن Signal هو في جزء كبير منه تطبيق من جانب العميل، فهناك بالتأكيد واجهة برمجة تطبيقات، ومن شبه المؤكد أنه يمكنك هندستها عكسيًا من الكود المصدري.
ولكن كما يقولون، فإن الاستخدام خارج Signal “غير مدعوم”، لذلك بينما قد تحصل على مساعدة من مجتمعهم، فلن يكون هناك ضمان لاستقرار هذه الواجهة أو المكتبات التي قد تحتاج إلى الاعتماد عليها في عالم RoR.
ستكون هناك بلا شك محاولات أخرى في أنظمة بيئية مختلفة موجودة في العديد من مستودعات GitHub التي قد لا تتم صيانتها بعد الآن ولا تعمل، ولكنها توفر بعض الأفكار.
ستحتاج إلى أن تكون قادرًا على ربط كل حساب مستخدم Discourse بكل حساب Signal مقابل بنفس الطريقة التي تم بها المخطط الحالي والحفاظ على مفاتيح خاصة محلية لكل مستخدم، وفك تشفير الرسائل ثم معالجتها.
إنه بالتأكيد ممكن، ولكنه قدر كبير بشكل غير متوقع من العمل المستمر، وليس أقلها لأنك بدون وثيقة لواجهة برمجة التطبيقات التي لم يكن من المفترض استهلاكها بواسطة Ruby on Rails (ولكنك لا تعرف أبدًا).
أعتقد أنك ستحتاج إلى الرغبة في ذلك بشدة لإنجازه. ، ما لم تتمكن من إلهام شخص ما لالتقاط هذا كمشروع شغف.
لقد ناقشت هذا سابقًا من منظور غير تقني مع موظفي المناقشة. في ألمانيا، تستخدم العديد من المجتمعات غير الربحية أنظمة الدردشة كمكانها الوحيد للتواصل الجماعي. ليس من السهل إقناعهم بأن المناقشة هي حل أفضل بكثير للتفاعل الرقمي “عالي الجودة”.
مع المزيد من الرؤى حول التفاصيل الفنية، أتفق الآن على أنه من الصعب حقًا (أكثر تكلفة) إنشاء رابط بين مجموعة دردشة إشارة كمصدر ومنصة مناقشة كهدف لنوع من “مرآة الاتصال الجماعي التلقائي”. الطريقة الأفضل هي إقناع الناس مباشرة بأن التحول إلى المناقشة هو أفضل بديل لـ signal/whatsapp وما إلى ذلك. ولكن لهذا سنحتاج إلى المزيد من التحسينات على واجهة “discourse mobile/android”، كما نوقش بالفعل في
شكراً لكما على المساهمة في هذا السؤال. كلما فكرت في الأمر أكثر، كلما اعتقدت أن تحسين، أو ربما إعادة اختراع Discourse Mobile ليصبح تطبيقًا أكثر أمانًا وقوة قد يكون استخدامًا أفضل للوقت والموهبة والكنز من محاولة دمج Signal.