{"_id":"5480aad4e952bb1a006b320c","category":{"_id":"54343531bfaa3d0800c4d4b0","pages":["54349c225b10711400c6c539","54349c905b10711400c6c53b","54370bea4e799808006da391","54370fa726469424002a6e19","5480aad4e952bb1a006b320c","5638d6c12fc5520d001a4cc9","568fe01b21fcf0190071d8fb"],"project":"54343170fa5527080064f449","version":"54343531bfaa3d0800c4d4af","__v":8,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2014-10-07T18:31:12.137Z","from_sync":false,"order":0,"slug":"documentation","title":"Documentation"},"parentDoc":null,"project":"54343170fa5527080064f449","version":{"_id":"54343531bfaa3d0800c4d4af","project":"54343170fa5527080064f449","__v":27,"forked_from":"54343170fa5527080064f44c","createdAt":"2014-10-07T18:47:13.086Z","releaseDate":"2014-10-07T18:47:13.086Z","categories":["54343531bfaa3d0800c4d4b0","543435b1edce040800409240","543435b9edce040800409241","543435bcedce040800409243","543435bfedce040800409244","543435c2edce040800409245","54370cc426469424002a6dfa","54370cf026469424002a6dfd","5437129d26469424002a6e2f","543712d226469424002a6e30","5480c8fd74904f1a00053c86","54aafc6eefb39016009e4d71","54ac1d36de18cc1400226e01","54ad59369219922100751732","54b41bcf4f25cb1600518d2c","54b533a3a806f40c0050d53c","54b54bbf96fe3c0b00d38d2a","54b688a27379a90c00f53a8a","54b699efbc1a46160005edfa","54b8191691011f0b00068804","54bfb002d03bfc0d0000e814","54bfb33ed03bfc0d0000e816","55a3e94e912a6e2300882cdb","55a56c370f354f0d00fd02a8","55e85ad034516037002e9325","5638ecb62fc5520d001a4cf9","572cba2fc310640e008f63d5"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"3.0.0","version":"3.0"},"__v":10,"user":"54343147fa5527080064f43f","updates":["54b97ca849aaa81e00179349"],"next":{"pages":[],"description":""},"createdAt":"2014-12-04T18:41:24.859Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"basic_auth":false,"results":{"codes":[]},"try":true,"auth":"never","params":[],"url":""},"isReference":false,"order":4,"body":"MediaSilo is based on a few basic principles. Understanding these concepts will make developing against the API easy and will set your project up for success.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Media Organization\"\n}\n[/block]\nAll media in MediaSilo is organized in projects. Projects are the core organizational layer that determines who has access to media. Assets are uploaded to projects, and users are added (or invited) to projects. Permissions are applied for each user on a project basis, so it is possible to add a user as a viewer to one project, and as a contributor to another. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Permissions\"\n}\n[/block]\nMediaSilo has a very flexible permission model consisting of two layers: Account level roles and project level permissions. Permissions are grouped into sets, given a name and are then applied to users on a project level.\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Permission\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"**Administrator**\",\n    \"0-1\": \"Has access to everything in the system, including billing, reports, and all resources (projects, QuickLinks, users, etc.). Typically, you would reserve a separate login for an administrator and not use this account on a daily basis.\",\n    \"1-0\": \"**Project Manager**\",\n    \"1-1\": \"Users marked as Project Managers can create new projects and invite users to these projects. They can also modify the permissions of users in their projects without affecting other projects, and they can remove users from projects they manage.\",\n    \"2-0\": \"**User**\",\n    \"2-1\": \"This is a basic user account that needs to be assigned to projects before being able to do anything.\"\n  },\n  \"cols\": 2,\n  \"rows\": 3\n}\n[/block]\nEach account comes with default project permission sets that can be customized. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Delegation of User Responsibilities\"\n}\n[/block]\nMediaSilo scales from small independent teams to enterprises with thousands of users. What makes this work in the concept of delegation of responsibilities. To understand how this works, let's consider two examples:\n\n**Small Team (1-20):** A 15-person post-house may assign one person to be the \"go-to\" MediaSilo administrator. That person is responsible for creating accounts and projects. The remaining team members are regular users in the system with different permissions assigned on a project level.\n\n**Medium Team (21-50):** In addition to a central administrator, trusted Project Managers are given the permissions to create new projects and invite users as needed. The administrator creates global permissions that project managers can use to assign to users. This could include \"Producer\", \"Press\", \"Contributor\", or \"Reviewer\" roles. In this hybrid scenario, both Administrators and Project managers maintain users, projects, and media. \n\n**Large Team (50+):** In larger teams, the central administrator role becomes overwhelming. Creating projects, assigning users, creating and managing user accounts can quickly turn into a time-consuming job. In this scenario, trusted Project Managers are given full responsibility over projects and users who can view media contained in those projects. A project can have multiple owners, which ensures that projects can be maintained even if the original project manager has moved on.\n \n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Scoping\",\n  \"body\": \"It is important to understand that all media is restricted by projects. Project Managers who invite external users can only share media the Project Manager has access to. This ensures that Project Manager B on Project B can not access media for Project A unless Project Manager B has been explicitly added to that project. Furthermore, Project Managers can only invite users to projects they created or are assigned ownership of.\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Media Storage\"\n}\n[/block]\nMediaSilo is built on Amazon's cloud infrastructure. Media is by default stored on S3. A popular option is to provide your own S3 account to take advantage of low storage prices. \n\nAll media requires a signature to be retrieved. This token is time-limited and may expire. Developers building front end applications should anticipate that media can expire. Expiration is indicated by the timestamp (in milliseconds) included in the URL signature.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Encoding\"\n}\n[/block]\nAll ingested media is encoded to ensure playback on as many devices as possible. As a developer, you can take advantage of derivatives that provide you with different proxy version of files that certain platforms require. For instance, you could use a webm derivative to target Firefox browsers and choose H264 for iOS devices. For more information on derivatives, take a look at [Asset Overview](http://docs.mediasilo.com/v3.0/docs/assets-overview).\n\nIt is currently not possible to skip encoding, but our team is working on streamlining ingest to defer encoding and make submitted video available immediately. Check out developer blog for updates. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Scopes\"\n}\n[/block]\nIn MediaSilo it is possible to manage completely autonomous and separate user groups. The most practical example is to separate all of Customer A and Project A from Customer B and Project B. \n\nWhat makes this possible is project level scoping. Every user is scoped by the projects they can see. A user sending a QuickLink will only be able to send private links to users that have access to the same project as the sending users. Likewise, a global search would only search project and folders a user has been assigned to.","excerpt":"","slug":"core-concepts","type":"basic","title":"Core Concepts"}
MediaSilo is based on a few basic principles. Understanding these concepts will make developing against the API easy and will set your project up for success. [block:api-header] { "type": "basic", "title": "Media Organization" } [/block] All media in MediaSilo is organized in projects. Projects are the core organizational layer that determines who has access to media. Assets are uploaded to projects, and users are added (or invited) to projects. Permissions are applied for each user on a project basis, so it is possible to add a user as a viewer to one project, and as a contributor to another. [block:api-header] { "type": "basic", "title": "Permissions" } [/block] MediaSilo has a very flexible permission model consisting of two layers: Account level roles and project level permissions. Permissions are grouped into sets, given a name and are then applied to users on a project level. [block:parameters] { "data": { "h-0": "Permission", "h-1": "Description", "0-0": "**Administrator**", "0-1": "Has access to everything in the system, including billing, reports, and all resources (projects, QuickLinks, users, etc.). Typically, you would reserve a separate login for an administrator and not use this account on a daily basis.", "1-0": "**Project Manager**", "1-1": "Users marked as Project Managers can create new projects and invite users to these projects. They can also modify the permissions of users in their projects without affecting other projects, and they can remove users from projects they manage.", "2-0": "**User**", "2-1": "This is a basic user account that needs to be assigned to projects before being able to do anything." }, "cols": 2, "rows": 3 } [/block] Each account comes with default project permission sets that can be customized. [block:api-header] { "type": "basic", "title": "Delegation of User Responsibilities" } [/block] MediaSilo scales from small independent teams to enterprises with thousands of users. What makes this work in the concept of delegation of responsibilities. To understand how this works, let's consider two examples: **Small Team (1-20):** A 15-person post-house may assign one person to be the "go-to" MediaSilo administrator. That person is responsible for creating accounts and projects. The remaining team members are regular users in the system with different permissions assigned on a project level. **Medium Team (21-50):** In addition to a central administrator, trusted Project Managers are given the permissions to create new projects and invite users as needed. The administrator creates global permissions that project managers can use to assign to users. This could include "Producer", "Press", "Contributor", or "Reviewer" roles. In this hybrid scenario, both Administrators and Project managers maintain users, projects, and media. **Large Team (50+):** In larger teams, the central administrator role becomes overwhelming. Creating projects, assigning users, creating and managing user accounts can quickly turn into a time-consuming job. In this scenario, trusted Project Managers are given full responsibility over projects and users who can view media contained in those projects. A project can have multiple owners, which ensures that projects can be maintained even if the original project manager has moved on. [block:callout] { "type": "warning", "title": "Scoping", "body": "It is important to understand that all media is restricted by projects. Project Managers who invite external users can only share media the Project Manager has access to. This ensures that Project Manager B on Project B can not access media for Project A unless Project Manager B has been explicitly added to that project. Furthermore, Project Managers can only invite users to projects they created or are assigned ownership of." } [/block] [block:api-header] { "type": "basic", "title": "Media Storage" } [/block] MediaSilo is built on Amazon's cloud infrastructure. Media is by default stored on S3. A popular option is to provide your own S3 account to take advantage of low storage prices. All media requires a signature to be retrieved. This token is time-limited and may expire. Developers building front end applications should anticipate that media can expire. Expiration is indicated by the timestamp (in milliseconds) included in the URL signature. [block:api-header] { "type": "basic", "title": "Encoding" } [/block] All ingested media is encoded to ensure playback on as many devices as possible. As a developer, you can take advantage of derivatives that provide you with different proxy version of files that certain platforms require. For instance, you could use a webm derivative to target Firefox browsers and choose H264 for iOS devices. For more information on derivatives, take a look at [Asset Overview](http://docs.mediasilo.com/v3.0/docs/assets-overview). It is currently not possible to skip encoding, but our team is working on streamlining ingest to defer encoding and make submitted video available immediately. Check out developer blog for updates. [block:api-header] { "type": "basic", "title": "Scopes" } [/block] In MediaSilo it is possible to manage completely autonomous and separate user groups. The most practical example is to separate all of Customer A and Project A from Customer B and Project B. What makes this possible is project level scoping. Every user is scoped by the projects they can see. A user sending a QuickLink will only be able to send private links to users that have access to the same project as the sending users. Likewise, a global search would only search project and folders a user has been assigned to.