User:Aleksejrs/ideas/federation: Difference between revisions

From GNU MediaGoblin Wiki
Jump to navigation Jump to search
(Created page with "== Selective media copying == # UserA owns GMG ServerA. # UserA goes to GMG ServerB and sees an image. # UserA puts URL of the image into his ServerA. # ServerA fetches the imag...")
 
(→‎Selective media copying: new location of the ticket)
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
It may be that things described here are described, and better described, at [[API]]. --[[User:Aleksejrs|Aleksejrs]] 15:44, 8 November 2011 (EST)

== Selective media copying ==
== Selective media copying ==


Line 6: Line 8:
# ServerA fetches the image from ServerB with all metadata, so it becomes available at ServerA.
# ServerA fetches the image from ServerB with all metadata, so it becomes available at ServerA.


* Access (both viewing and copying) to the image might require authentification.
* Access (both viewing and copying) to the image might require view/access rights.
* The result should (must at least if authentification was required) be marked private by default.
* The result should (must at least if the source is non-public) be marked private by default.
* It should be possible for the result to have a visible reference to its source.
* It should be possible for the result to have a visible reference to its source.
* ServerB may be notified of the copying, so that it can link to the result, if it chooses to ([http://issues.mediagoblin.org/ticket/268 #268], migrated from http://bugs.foocorp.net/issues/604).


=== Another use-case ===
=== Another use-case ===
Line 17: Line 20:
== FidoNet-inspired group mirroring ==
== FidoNet-inspired group mirroring ==


To be written. Here is a StatusNet feature request that came to be after the discussion: http://status.net/open-source/issues/3407
Here is a StatusNet feature request that came to be after the discussion: http://status.net/open-source/issues/3407

# GMG has a concept of something like “groups” (as of this writing it probably does not yet). Imagine groups like in Identi.ca — see the link above.
# A group originates at ServerA, and is also at ServerB.
# When somebody at ServerA or ServerB posts a media into the group (or marks it as being in that group), it appears in the group at both ServerA and ServerB.

* A group may have a moderator.
* A server admin may refuse a media to be on his server (including: pre-moderation).
* ServerC may receive this group even from a server other than the one from where the group originates, or from where the file originates.
** Bad: that might create a moderatorless version of the group at a group of servers, or similar MITM attacks on the group, but that’s its decentralization, and it is optional.
** Bad: a complex network of servers can have broken links (or worse, recreate FidoNet politics!).
* To protect the group against broken links, servers may connect to each other as a ring, downloading only the files they don’t have (keeping information about where the file comes from, to be able to remove files/versions coming from a particular server?).

Latest revision as of 15:44, 25 June 2013

It may be that things described here are described, and better described, at API. --Aleksejrs 15:44, 8 November 2011 (EST)

Selective media copying

  1. UserA owns GMG ServerA.
  2. UserA goes to GMG ServerB and sees an image.
  3. UserA puts URL of the image into his ServerA.
  4. ServerA fetches the image from ServerB with all metadata, so it becomes available at ServerA.
  • Access (both viewing and copying) to the image might require view/access rights.
  • The result should (must at least if the source is non-public) be marked private by default.
  • It should be possible for the result to have a visible reference to its source.
  • ServerB may be notified of the copying, so that it can link to the result, if it chooses to (#268, migrated from http://bugs.foocorp.net/issues/604).

Another use-case

  1. UserA has private ServerA at home (possibly not accessible from outside), and an account at remote ServerB.
  2. UserA stores media in ServerA (possibly uploading by copying to a directory), and has the option of uploading all or parts of it to his ServerB account.

FidoNet-inspired group mirroring

Here is a StatusNet feature request that came to be after the discussion: http://status.net/open-source/issues/3407

  1. GMG has a concept of something like “groups” (as of this writing it probably does not yet). Imagine groups like in Identi.ca — see the link above.
  2. A group originates at ServerA, and is also at ServerB.
  3. When somebody at ServerA or ServerB posts a media into the group (or marks it as being in that group), it appears in the group at both ServerA and ServerB.
  • A group may have a moderator.
  • A server admin may refuse a media to be on his server (including: pre-moderation).
  • ServerC may receive this group even from a server other than the one from where the group originates, or from where the file originates.
    • Bad: that might create a moderatorless version of the group at a group of servers, or similar MITM attacks on the group, but that’s its decentralization, and it is optional.
    • Bad: a complex network of servers can have broken links (or worse, recreate FidoNet politics!).
  • To protect the group against broken links, servers may connect to each other as a ring, downloading only the files they don’t have (keeping information about where the file comes from, to be able to remove files/versions coming from a particular server?).