{"id":20641903,"url":"https://github.com/ungive/rfc-media-domain","last_synced_at":"2025-05-10T08:31:03.951Z","repository":{"id":238176018,"uuid":"795993240","full_name":"ungive/rfc-media-domain","owner":"ungive","description":"RFCs for extending existing system APIs of desktop operating systems to supply information about where currently playing media is coming from, by using internet domains as source identifiers.","archived":true,"fork":false,"pushed_at":"2024-05-04T18:45:09.000Z","size":9,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-05-08T03:55:58.645Z","etag":null,"topics":["chrome","firefox","linux","macos","mediaremote","mpris2","rfc","windows","winrt"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ungive.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-05-04T16:04:56.000Z","updated_at":"2024-12-02T01:59:36.000Z","dependencies_parsed_at":"2024-05-04T19:38:20.269Z","dependency_job_id":null,"html_url":"https://github.com/ungive/rfc-media-domain","commit_stats":null,"previous_names":["jonasberge/rfc-media-domain","ungive/rfc-media-domain"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ungive%2Frfc-media-domain","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ungive%2Frfc-media-domain/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ungive%2Frfc-media-domain/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ungive%2Frfc-media-domain/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ungive","download_url":"https://codeload.github.com/ungive/rfc-media-domain/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253389685,"owners_count":21900798,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["chrome","firefox","linux","macos","mediaremote","mpris2","rfc","windows","winrt"],"created_at":"2024-11-16T16:07:12.603Z","updated_at":"2025-05-10T08:31:02.406Z","avatar_url":"https://github.com/ungive.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# RFCs for offering Source Information with Desktop Media\n\n\u003e WORK IN PROGRESS\n\u003e\n\u003e This document and the documents in the root of this repository\nare a work in progress.\nIf you are an individual who works on\nthe Windows operating system,\nthe Macintosh operating system,\nthe Linux kernel or any Linux distribution,\nChromium, Firefox or any other browser,\nfeel free to reach out by opening an issue in this repository,\nby opening a pull request,\nor by sending an e-mail to the author.\n\n## Abstract\n\nThe documents in the root of this repository\noutline how system APIs that already exist\nto retrieve metadata information about media playback on desktop computers\ncould be extended to additionally supply information\nabout which internet service is used as the underlying source of the media,\nidentified by its internet domain name.\nThe purpose of this is to give clients of those system APIs the opportunity\nto discern where media is coming from exactly,\nwhen it is impossible to tell by the name of the application\nthat is playing the media alone.\nMore specifically, it would be possible to tell which online service is used,\nfor media that is being played inside an internet browser,\nwhich is otherwise impossible with the current state of available system APIs.\n\nThis document (README.md) only acts as an overview\nfor suggested changes to existing system APIs and applications,\nwhich are further detailed in the individual RFC documents in this repository.\nFor implementation details, please consult these individual documents.\n\n## Introduction\n\nThe system APIs of modern operating systems offer programmable interfaces\nto both get information about currently playing media on a desktop computer,\nand to communicate to the operating system\nwhich media the application that interfaces with the system API\nis currently playing.\nWith these APIs applications can retrieve information\nabout what media is being played on the system,\nwhich is useful for many different purposes\nthat are already established and won't be reiterated in detail.\n\n## Identifying the Media Source Application\n\nWith all system APIs it is already possible\nto retrieve the name of the application\nthat is playing a specific piece of media.\n\nOn the Windows operating systems this is either the executable name\nor an \"Application User Model ID\"\n[[AppUserModelID](https://learn.microsoft.com/en-us/windows/win32/shell/appids)].\n\nOn the Macintosh operating system this is the bundle identifier\n[[CFBundleIdentifier](https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier)].\n\nOn Linux operating systems this is application name\n*[citation needed]*.\n\n## Identifying the real Media Source\n\nThe problem arises when the application name does not constitute\nto identifying the underlying source of the media anymore\nbecause the application itself is so generic in its nature,\nthat it can play media from multiple different sources\nor any source in general.\nThe best example of this are internet browsers,\nwhich can be used to visit online websites\nthat can and will play anything a user of that browser wishes for.\nThe name of the application does not suffice anymore,\nto be able to tell the which entity or service the media belongs to,\nwhether it is a local file or if it is being streamed from a server.\nIt could be from a music streaming service,\nit could be a video from a video-on-demand service\nor it could really just be a generic local audio file.\n\nMPRIS [[MPRISv2](https://specifications.freedesktop.org/mpris-spec/2.2/)]\nalready provides a means of identifying a \"track\",\na piece of media, in the context of its media player (the application)\nwith the \"mpris:trackid\" field\n[[MPRISv2:Metadata](https://www.freedesktop.org/wiki/Specifications/mpris-spec/metadata/#mpris:trackid)].\nWhile this does not help with identifying the source of the media,\nthe implementation of it is similar to what is needed\nto identify the media source.\nThere should be some identifier,\nwhich helps in discerning where media is coming from.\n\n## Using Domain Names to identify the Media Source\n\n\u003e This is a draft and might see changes in the future.\n\nIf an application uses a *single source* it is in most cases either\na media player for local audio files (offline players)\nor a desktop client for a streaming service\n*[citation needed]*.\nIn these cases the application name is sufficient,\nto identify where the media is coming from.\n\nWith applications that can play media from multiple different sources,\nthis usually means that these *different sources* are *web services*\n(as is already the case with desktop clients for streaming services,\nwhich also make use of web services).\n\nThe idea is that system APIs of desktop computers\nshould not only supply the name of the application,\nbut, in addition to that, the name of the web service\nfrom which the media is retrieved.\n\nSince using the concept of a \"web service\" is rather specific,\nit makes sense to generalize the concept\nand find an identifier that is more generic, while still being unique.\nThe first thing that comes to mind,\nwhen it's about globally identifying something on the internet,\nis internet domains.\n\nInternet domains are widely used, well-supported, globally unique\nand each service provider or vendor of a major application (usually) has one.\nInternet domains are used in the following contexts\nto allow for unique identification of entities:\n\n- Java package names use domains in reverse-DNS format *[citation needed]*.\n- Applications for the Macintosh operating system use bundle identifiers,\n  which are domains in reverse-DNS format\n  [[CFBundleIdentifier](https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier)].\n- Web services, by nature, are accessible over the internet,\n  which is where internet domains are at home.\n  Usually, every notable web service also has a domain name\n  with which it can be identified.\n\nAn application would, in addition to all media metadata,\nsupply a domain name that identifies the service that was used\nto retrieve the media, in case any service was used as a source.\nSpecific implementation details are discussed in the individual RFC documents.\n\n## Examples\n\nTo get a better understanding of the material,\nhere are some examples where the described type of identifier can be useful.\nFor the sake of brevity, everything that identifies a particular piece of media\nis summarized under the \"Media\" column,\nwhich might include the title of the media and the artist.\n\nIn all examples the following columns are used:\n\n- **Application Name**: The name of the application that is playing the media.\n- **Application Identifier**: The identifier for the application,\n  which is unique for every operating system.\n  With these examples Windows executable names are used.\n- **Media**: A particular piece of media that is played by the application,\n  formatted as \"Title\" or \"Title - Artist\".\n  In reality there can be much more information about the media\n  that is supplied by the operating system,\n  for the sake of brevity this is summarized here as a short string.\n- **Media Source Identifier**: The proposed identifier\n  for identifying the underlying source of the media\n  that is played by the application.\n  In this case domains are used in reverse-DNS format.\n- **Vendor URL**: A URL to the website of\n  the application vendor or service provider,\n  to show the relationship between the *Media Source Identifier*\n  and the internet domain of the application or service provider.\n\n### Example 1: Desktop Applications\n\n| Application Name | Application Identifier | Media | Media Source Identifier | Vendor URL |\n|-|-|-|-|-|\n| Spotify | Spotify.exe | Allegro - Bach | `com.spotify` (optional) | https://spotify.com |\n| TIDAL | TIDAL.exe | Fur Elise - Ludwig van Beethoven | `com.tidal` (optional)  | https://tidal.com |\n| foobar2000 | foobar2000.exe | Allegro - Bach | `org.foobar2000` (optional)  | https://www.foobar2000.org |\n\nNote that Media Source Identifiers are optional here.\nApplication developers do not have to choose to supply this identifier,\nas it is already apparent from the application name and application identifier\nwhere the media is originating from.\nThese examples are here to show that application identifiers *can be*\nsufficient to help identify where media is coming from.\nWhere the Media Source Identifier really shines is the next example,\nwhich shows where the application identifier itself is not sufficient\nto identify where the media is coming from.\n\n### Example 2: Multimedia Desktop Applications\n\nIn these examples only internet browsers are used.\n\nAdditional columns:\n\n- **Website URL**: The URL of the website which is playing the media\n  inside the browser.\n\n| Application Name | Application Identifier | Media | Media Source Identifier | Website URL | Vendor URL |\n|-|-|-|-|-|-|\n| Firefox | firefox.exe | Allegro - Bach | `com.spotify` | https://open.spotify.com | https://www.mozilla.org |\n| Google Chrome | chrome.exe | Allegro - Bach | `com.spotify` | https://open.spotify.com | https://www.google.com |\n| Google Chrome | chrome.exe | Fur Elise - Ludwig van Beethoven | `com.tidal` | https://listen.tidal.com | https://www.google.com |\n\nAs we can see, we are still able to identify Spotify and TIDAL\nas the underlying source for the media that is being played inside a browser.\nThe application name or application identifier itself\ndoes not communicate this information,\nbut when the browser supplies the Media Source Identifier,\nthis information becomes available to us.\n\n## Deriving the Media Source Identifier\n\nDesktop applications as described in example 1\ncan simply use their own domain names.\n\nMultimedia desktop applications as described in example 2\nneed some way to derive the Media Source Identifier from its content.\n\n### Web Browsers\n\nWeb browsers may derive Media Source Identifiers from the website domain name\nthat is playing the media.\nIf media is e.g. played on `www.example.com`,\nthe Media Source Identifier could either be `com.example.www`\nor `com.example`.\nThe exact details of which should or could be preferred\nis outlined in the individual RFC documents.\n\n### Other Multimedia Applications\n\nMultimedia applications that work in a similar fashion to web browsers,\ni.e. they retrieve media from an online service that has an internet domain,\nshould use the same logic as web browsers\nto derive the Media Source Identifier.\n\nIf a multimedia application does not get media from an online service,\nthe Media Source Identifier should be empty.\n\n## Request for Comments\n\nThe suggested changes in this repository heavily rely on the cooperation\nwith other individuals,\nnamely those who have an impact\non the design of system APIs for desktop operating systems,\nwhich provide media playback information.\nIf you read this, you are encouraged to contribute,\nby opening an issue, making a pull request\nor forwarding a link to this repository to others.\n\n## Individual RFC Documents\n\n- [RFC-01](./rfc-00-media-source-identifier.md): Specification of Media Source Identifiers\n- [RFC-01](./rfc-01-linux-mpris.md): Extending Linux MPRIS to support Media Source Identifiers\n- [RFC-02](./rfc-02-windows-winrt.md): Extending Windows WinRT to support Media Source Identifiers\n- [RFC-03](./rfc-03-macos-mediaremote.md): Extending Macintosh's MediaRemote Framework to support Media Source Identifiers\n- [RFC-04](./rfc-04-web-browsers.md): Extending web browsers to supply Media Source Identifiers\n\n## References\n\n[AppUserModelID]  \nWindows App Development  \nApplication User Model IDs (AppUserModelIDs)  \nhttps://learn.microsoft.com/en-us/windows/win32/shell/appids\n\n[CFBundleIdentifier]  \nApple Developer  \nCFBundleIdentifier  \nhttps://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier\n\n[MPRISv2]  \nFreedesktop.org Specifications  \nMPRIS D-Bus Interface Specification  \nhttps://specifications.freedesktop.org/mpris-spec/2.2/\n\n[MPRISv2:Metadata]  \nFreedesktop.org Specifications  \nMPRIS v2 metadata guidelines  \nhttps://www.freedesktop.org/wiki/Specifications/mpris-spec/metadata\n\n## Copyright Notice\n\nCopyright (c) 2024 Jonas van den Berg  \nAll rights reserved.\n\nIf you need a license for any of the information in this repository,\nplease contact me.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fungive%2Frfc-media-domain","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fungive%2Frfc-media-domain","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fungive%2Frfc-media-domain/lists"}