سيقومون بتخزين بيانات ActivityPub المرتبطة بعلامة تؤدي دور ممثل ActivityPub. لا أحتاج إلى أي تسلسل لأي أجزاء من العميل في discourse/discourse. لن يرى المستخدم هذه البيانات في أي جزء من عميل discourse/discourse العادي. سيتم تسلسل البيانات إلى عميل المسؤول، جنبًا إلى جنب مع بيانات أخرى، ومع ذلك تتم إدارة ذلك بواسطة المكون الإضافي في مسارات مسؤول المكون الإضافي المخصصة. كما ذكرت، فإن التسلسل في مسارات علامات discourse/discourse الحالية (أو مُسلسل الموقع) سيكون صعبًا، وذلك لأسباب مختلفة وليس شيئًا أرغب في محاولة القيام به، ولهذا السبب لم أضف طرق واجهة برمجة تطبيقات قابلة للتحميل المسبق أو قابلة للتحرير.
بالإضافة إلى وجود واجهة برمجة تطبيقات مستقرة للعمل معها، فإن السبب في تفضيلها في مكون ActivityPub الإضافي هو أن المكون الإضافي يخزن أنشطة ActivityPub في مجموعة منفصلة من نماذج البيانات، وهي جداول discourse_activity_pub_*، والتي تتكامل بعد ذلك مع discourse/discourse عبر واجهات برمجة التطبيقات المحددة للمكون الإضافي والحقول المخصصة للنماذج الأساسية. يوجد بعض التكرار المتعمد هنا لضمان الفصل السليم للاهتمامات بين بيانات Discourse و ActivityPub. نظرًا لأن Discourse و ActivityPub لديهما سلسلة من المفاهيم ونماذج البيانات المترابطة، ولكنها مختلفة، فإن الحفاظ على تمييز واضح بين بيانات ActivityPub وبيانات discourse/discourse ضروري للحفاظ على بعض الوضوح (والعقلانية) في مكون إضافي كبير ومعقد. يعد استخدام الحقول المخصصة كنقطة تكامل مفيدًا جدًا في الحفاظ على هذا الفصل نظيفًا ومستقرًا.
يوجد شرح موجز لهذا في ملف README الخاص بالمكون الإضافي.