[[!comment format=mdwn
 username="joey"
 subject="""comment 1"""
 date="2017-03-30T16:51:24Z"
 content="""
Using a remote for this seems problimatic, because the remote is not
pointing at a single well-defined data store, but instead whatever peers
happen to exist on the network.

For one, `copy --to=udp-multicast` would not try to send files that it thinks
are already located in that remote. I suppose this could be dealt with by
making the transfers always seem to fail, so it never thinks that the
multicast remote has any files.

But then, `copy --from=udp-multicast` would not try to receive files,
unless it thinks they're in that remote. And we just established it should
not think any files are in that remote. So that's a problem.

Also, the copy from/to would need to be operating on the same file at the
same time, which seems problimatic. If a receiving git-annex is a little
slower than the sender, or is operating on a slightly different set of
files, it would then miss a file being broadcast by the sender.

These issues seem to point to this needing to use some other, more
special-purpose commands for muticast.

----

It probably needs encryption, both for privacy and to ensure that files
are being received from the sender you intended, and not someone else
who might be broadcasting the contents of a different repository.

Here's how to set up encryption and authentication with uftp,
so that both client and server actually encrypt and check that they're
talking with a known entity. It took a while to figure out.

Client:

	uftp_keymgt -g rsa:512 ~/client_key
	# Parse the fingerprint value from its output; does not
	# seem to be a better way, except perhaps using openssl to examine
	# the key file. This is CLIENT_FINGERPRINT

	# Pick a UID for the client. This is an 8-diget hex number,
	# which needs to be unique across clients. Default is based on IP
	# adddres, but for git-annex it could be derived from the git-annex
	# UUID.	This is CLIENT_UID.

Server:

	uftp_keymgt -g rsa:512 ~/servant_key
	# Parse the SERVER_FINGERPRINT from its output.
	
	# Pick a SERVER_UID for the server.

Client:

	# create a file "authlist" that contains "$SERVER_UID|$SERVER_FINGERPRINT"

	uftpd -E -d -D/tmp/xx -k ~/client_key -U $CLIENT_UID -S '@authlist'

Server:

	# create file "authlist" that contains "$CLIENT_UID|$CLIENT_FINGERPRINT"
	# lines for each allowed client

	uftp -c -Y aes256-cbc -h sha1 -k ~/server_key -U $SERVER_UID -H '@authlist' file_to_send

----

Notice that the client and server UID and key generation steps above 
are the same. So, a command like `git annex multicast --gen-address`
could be run on both the server and clients, and could store
the addresses in the git-annex branch. 
The uftp authlist file would be derived from all known such addresses.

(Unlike `p2p --gen-address`, where the address allows connecting with
and authentication with a remote over TOR, these multicast addresses
are safe to make public.)

The process of setting up a multicast classroom would then be:

1. Teacher runs `git annex multicast --gen-address; git annex sync`
2. Students each run `git annex multicast --gen-address; git annex sync`
3. Teacher runs `git annex sync` once all the students have generated addresses.  
   (Now the students all have received the teacher's address, and the teacher
   has received all the student's addresses.)
4. Students each run `git annex multicast-receive`, which listens for 
   files going by and stores them.
5. Once the students are listening (*ahem*), teacher runs
   `git annex multicast-send [file]` to distribute files.
"""]]