7
1
Fork
You've already forked interop
0

consent-first-notes #11

Open
MaciAc wants to merge 4 commits from consent-first-notes into main
pull from: consent-first-notes
merge into: fairplayer:main
fairplayer:main
fairplayer:discovery-tiers
fairplayer:smaller-ci-image
fairplayer:js-restructure
fairplayer:repo-info
fairplayer:purchase-proto
fairplayer:ci-image-optimisation
fairplayer:ci
fairplayer:add-essays
fairplayer:use-mdbook
fairplayer:canimus-pydantic-schema
fairplayer:streaming-spec
fairplayer:nlnet-app
fairplayer:rough-initial-plan

Some first notes on the consent part of the interop spec

Some first notes on the consent part of the interop spec
@ -6,0 +4,4 @@
It could be implemented as a plug-in for [Canimus, the protocol proposed as a content data model](/content/data-model.md). A proposal is being drafted [here](/consent/data-model.md).
## License notice
Several frameworks for license noticing can be taken into account. Copyright and Creative Commons are already defined in Canimus spec for [albums](https://github.com/PlaidWeb/Canimus/blob/main/format.md#album) and [tracks](https://github.com/PlaidWeb/Canimus/blob/main/format.md#track). Ohter license noticing mechanisms from web 3 could be taken into account: Smart contract address or IPFS hash of a legal agreement.
Owner
Copy link

Possibly the best approach could be the official URI to the license spec, and maybe a short name, and leverage existing lists/directories of those (like https://creativecommons.org/licenses/list.en#licenses-40 for creative commons).

There remains a challenge of whether the players may have some form to enforce the license or not, but there could be well defined rules as to how a compliant player should provide a path to said license.

Possibly the best approach could be the official URI to the license spec, and maybe a short name, and leverage existing lists/directories of those (like https://creativecommons.org/licenses/list.en#licenses-40 for creative commons). There remains a challenge of whether the players may have some form to enforce the license or not, but there could be well defined rules as to how a compliant player should provide a path to said license.
@ -6,0 +21,4 @@
`user_paid == true`: Limit disabled after micropayment.
`current_time > expiration`: Limit auto-disables after a date.
`user.subscription_active == true`: Bypass for subscribers.
Owner
Copy link

Ha interesting but this will be challenging.

Because this applies to full-blown services (with user accounts) like Mirlo we need to consider how much of this should just be enforced by the service and not left to the good will of the player.

What I mean is that maybe a different approach could be, if rules are user-specific or dynamic, the player needs to query "which rules apply to this (work, user, location, etc...) right now?". So this could be included as part of the "streaming protocol".

Both the static "these are the rules so you know" and per-user dynamic checks (the server can enforce them) can be complementary.

Ha interesting but this will be challenging. Because this applies to full-blown services (with user accounts) like Mirlo we need to consider how much of this should just be enforced by the service and not left to the good will of the player. What I mean is that maybe a different approach could be, if rules are user-specific or dynamic, the player needs to query "which rules apply to this (work, user, location, etc...) right now?". So this could be included as part of the "streaming protocol". Both the static "these are the rules so you know" and per-user dynamic checks (the server can enforce them) can be complementary.
@ -6,0 +12,4 @@
### Playback limit types
- **Time-based range limit**: Available only in a start/end timestamp range.
- **Play count**: Maximum number of streams per user per time window (e.g., 3 streams/day).
- **Concurrent stream limit**: Number of streams per user at the same time.
Owner
Copy link

Not sure what concrete situation you mean here by "at the same time"

Not sure what concrete situation you mean here by "at the same time"
This pull request has changes conflicting with the target branch.
  • docs/specs/consent/data-model.md
View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin consent-first-notes:consent-first-notes
git switch consent-first-notes

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main
git merge --no-ff consent-first-notes
git switch consent-first-notes
git rebase main
git switch main
git merge --ff-only consent-first-notes
git switch consent-first-notes
git rebase main
git switch main
git merge --no-ff consent-first-notes
git switch main
git merge --squash consent-first-notes
git switch main
git merge --ff-only consent-first-notes
git switch main
git merge consent-first-notes
git push origin main
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
fairplayer/interop!11
Reference in a new issue
fairplayer/interop
No description provided.
Delete branch "consent-first-notes"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?