مشخصات RSS 2.0 و تگ Enclosure: دایرکتوری‌های پادکست چگونه متادیتا را می‌خوانند و اپیزودها را پخش می‌کنند

اواخر سال ۲۰۰۰، در یکی از اتاق‌های کنفرانس کمبریجِ ماساچوست، دیو واینر (Dave Winer)، توسعه‌دهنده نرم‌افزار، تنها یک عنصر جدید XML را در مشخصات RSS 0.92 تایپ کرد: <enclosure>. این یک اضافه شدن بی‌سروصدا و متواضعانه بود؛ صرفاً برای اینکه وبلاگ‌ها بتوانند مثل یک فایل پیوست در ایمیل، یک فایل صوتی را به پست‌های متنی خود بچسبانند.

حالا، بیست و شش سال بعد، همان یک خط کد تبدیل به ستون حمالِ صنعت جهانی و ۲۳ میلیارد دلاری پادکست شده است. هر بار که شنونده‌ای روی گوشی هوشمندش دکمه پلی را لمس می‌کند، درخواستی را اجرا می‌کند که تبارش مستقیماً به همان اتاق کنفرانس برمی‌گردد.

هیئت مشورتی RSS در همان ابتدای مستنداتش می‌گوید: «RSS لهجه‌ای از XML است.» این هیئت، استاندارد RSS 2.0 را در سال ۲۰۰۳ نهایی کرد و چارچوبی مینیمالیستی ساخت که سادگی را به دسته‌بندی‌های طاقت‌فرسا ترجیح می‌داد. طبق آن مشخصات پایه، یک فید معتبر برای کار کردن فقط و فقط به سه عنصر در کانال خود نیاز دارد: یک عنوان، یک لینک و یک توضیحات.[1]

خود تگ <enclosure> هم به همین اندازه بی‌آلایش و ساده است. مشخصات RSS 2.0 دیکته می‌کند که این تگ برای کار کردن دقیقاً به سه ویژگی نیاز دارد. اولی یک آدرس اینترنتی (URL) است که نشان می‌دهد فایل MP3 کجا میزبانی می‌شود. دومی ویژگی طول (length) است که حجم فایل را به بایت مشخص می‌کند. و سومی ویژگی نوع (type) است که نوع استاندارد MIME فرمت صوتی را تعریف می‌کند.[1]

آرشیو تاریخی ویکی‌پدیا درباره enclosure در RSS اشاره می‌کند که تا ژوئیه ۲۰۰۵، این تگ به طور جهانی توسط پادکچرها پذیرفته شده بود و جایگاه خود را به عنوان مکانیزم تحویل برای محتوای صوتی اپیزودیک تثبیت کرد. ادغام پادکست‌ها در نسخه ۴.۹ آی‌تیونز (iTunes) اپل در همان سال، این تگ را از یک ابزار وبلاگ‌نویسی حاشیه‌ای به یک کانال توزیع رسانه جمعی تبدیل کرد.[3]

اما با انفجار این رسانه، آن چارچوب مینیمالیستی سال ۲۰۰۳ برای پلتفرم‌های تجاری ناکافی به نظر رسید. امروز، آن استاندارد باز و آزاد، بی‌سروصدا جای خود را به مجموعه‌ای سفت‌وسخت از قوانین نانوشته متادیتا داده است؛ قوانینی که توسط دایرکتوری‌های کنترل‌کننده دسترسی شنوندگان دیکته می‌شوند.

سند رسمی مشخصات پادکست اسپاتیفای (Spotify) این تغییر مسیر را به بهترین شکل نشان می‌دهد. در حالی که هیئت مشورتی RSS فقط سه تگ می‌خواهد، اسپاتیفای ۱۱ فیلد مجزا را اجباری کرده است تا موتور پردازشگرش اصلاً به یک برنامه نگاه بیندازد. مستندات پشتیبانی اسپاتیفای با لحنی قاطع می‌گوید: «پادکست شما باید دارای عنوان، تصویر و حداقل یک اپیزود منتشر شده باشد» و برای هر عنصر هم قوانین فرمت‌بندی سفت‌وسختی اضافه می‌کند.[2]

این اختلاف، یک تنش فنی جذاب ایجاد می‌کند. در یک سو، استاندارد خالص و باز RSS 2.0 قرار دارد که مدافعان اولیه وب سینه‌چاک آن هستند. در سوی دیگر، واقعیتِ به‌شدت دستکاری‌شده و پر از فضاهای نام (namespace) پلتفرم‌هایی مثل اسپاتیفای و PRX ایستاده است؛ پلتفرم‌هایی که تولیدکنندگان محتوا را مجبور می‌کنند تگ‌های اختصاصی را به فایل‌های XML خود تزریق کنند تا شاید در الگوریتم‌ها جایگاهی به دست بیاورند.

مستندات میز کمک PRX این الزامات مدرن را با زبانی بی‌پرده بیان می‌کند. یک فید معتبر باید شامل تگ‌های خاص <itunes:image> و <itunes:category> باشد؛ عناصری که فضای نام اختصاصی اپل را برای سازماندهی جهانی محتوا قرض می‌گیرند. PRX با پیوند زدن یک الزام بصری سخت‌گیرانه به یک پروتکل توزیع مبتنی بر متن، اعلام می‌کند: «کاور آرت شما باید حداقل ۱۴۰۰ در ۱۴۰۰ پیکسل باشد.»[5]

سیستم مدیریت محتوای صوتی BeyondWords در ژانویه ۲۰۲۲ تحلیلی منتشر کرد که تاکید داشت بهینه‌سازی فید RSS پادکست دیگر ربطی به رعایت اصول اولیه XML ندارد. تیم سردبیری BeyondWords متوجه شد که تگ‌گذاری صحیح متادیتا، جایگاه الگوریتمی را تعیین می‌کند و خاطرنشان کرد که جا انداختن پرچم‌های محتوای حساس (explicit) یا تگ‌های نوع اپیزود می‌تواند دسترسی یک برنامه را در دایرکتوری‌های بزرگ به شدت محدود کند.[6]

سادگی تگ اولیه enclosure حالا پیچیدگی عظیم متادیتای پیرامونش را پنهان می‌کند. وقتی یک تولیدکننده محتوا در سال ۲۰۲۶ یک فایل صوتی استاندارد ۵۰ مگابایتی را آپلود می‌کند، پلتفرم میزبان یک سند XML تولید می‌کند که ممکن است فقط برای توصیف مشارکت‌کنندگان، لایسنس و نشانگرهای فصل (chapter markers) همان یک اپیزود، ۲۰۰ خط کد داشته باشد.

این تورم کُد، تولیدکنندگان مستقل را مجبور به یک بندبازی همیشگی می‌کند. آیا باید یک فید سبک و قابل خواندن برای همه بسازند که کمترین پهنای باند سرور را مصرف کند، یا فایل XML خود را با فضاهای نام مخصوص پلتفرم‌ها باد کنند تا دل موتورهای پردازشگر غول‌های فناوری را به دست بیاورند؟

«پروژه استانداردهای پادکست» (PSP) که به صورت مشارکتی در گیت‌هاب (GitHub) میزبانی می‌شود، دقیقاً برای حل همین اصطکاک به وجود آمد. مشخصات PSP-1 با جزئیات توضیح می‌دهد که دایرکتوری‌های مدرن چگونه باید فیدها را بخوانند و یک فضای نام یکپارچه به نام <podcast:> را پیشنهاد می‌دهد تا جایگزین تگ‌های پراکنده و اختصاصی شود که در حال حاضر بر اکوسیستم تسلط دارند.[4]

مستندات PSP-1 توضیح می‌دهد: «فضای نام پادکست مجموعه‌ای از عناصر XML است» که طراحی شده تا ویژگی‌هایی مثل متن پیاده‌سازی شده (transcripts)، لینک‌های حمایت مالی و نشانگرهای فصل را در تمام اپلیکیشن‌های پشتیبانی‌کننده استاندارد کند. این پروژه ۱۴ تگ پیشنهادی را معرفی می‌کند که هدفشان شکستن وابستگی صنعت به معماری قدیمی <itunes:> اپل است.[4]

پذیرش این استاندارد جدید همچنان میدان نبرد اصلی برای آینده فنی پادکستینگ است. در حالی که اپلیکیشن‌های مستقلی مثل Pocket Casts و Overcast تگ‌های PSP-1 را ادغام کرده‌اند، دایرکتوری‌های تجاری بزرگ در به‌روزرسانی موتورهای پردازشگر خود کندتر عمل کرده‌اند و این فضای نام باز را در پلتفرم‌هایی که بیشترین ترافیک را هدایت می‌کنند، تا حدی بی‌اثر گذاشته‌اند.

معماری پادکستینگ همچنان یک گواه نادر و ماندگار از دوام استانداردهای اولیه وب است. تگ <enclosure> که به عنوان یک ایده ثانویه در اتاق کنفرانسی در ماساچوست متولد شد، همچنان روزانه میلیون‌ها ساعت صدا را توزیع می‌کند و ثابت می‌کند که یک پروتکل ساده و قابل توسعه می‌تواند از پلتفرم‌هایی که روی آن ساخته شده‌اند، بیشتر عمر کند.

آزمون واقعی این اکوسیستم در جنگ‌های ادامه‌دار فضاهای نام نهفته است. در حالی که پروژه استانداردهای پادکست برای پذیرش جهانی تگ <podcast:transcript> در ۱۵ اپلیکیشن بزرگ تا پایان سال ۲۰۲۶ فشار می‌آورد، این صنعت باید تصمیم بگیرد که آیا یک استاندارد باز جدید را در آغوش بکشد یا به وصله پینه کردن چارچوب ۲۶ ساله واینر با افزونه‌های اختصاصی ادامه دهد.[4]