[ticker-dev] Ticker group "invitation" attachments

[David Arnold]

-->"Matthew" == Phillips, Matthew <Matthew.Phillips at dsto.defence.gov.au> writes:

  Matthew> I probably should have made it clearer that I intend this
  Matthew> as the payload of a MIME attachment rather than as a
  Matthew> notification format. So the "tricks" we've used for version
  Matthew> numbers and lists to make it possible to intelligently
  Matthew> subscribe to notifications in that format have given way to
  Matthew> what (I think) are more human-friendly.

Ahh, but you've stumbled on my (not-so) hidden agenda: I'd like to be
able to use the same syntax (and more specifically, the same code) to
send subscription events to my multiple tickertapes ...

  >> How does this work -- if you sent me this message, where would I
  >> get the key values from?  If I already had them, isn't it likely
  >> that mine would have different names to yours? (ie. "My Private
  >> Key" would be a fine key name, but not so good when sent to
  >> someone else)

  Matthew> However, I basically intend this to be used in the scenario
  Matthew> where I'm setting up a new secure group and email the key
  Matthew> around (or whatever) and then send out an invitation on
  Matthew> ticker (in the case where we already have an appropriate
  Matthew> key, the first step can be skipped).

If you're going to send the key around in email, you might as well
attach the invitation as well -- then the receiver can "open" the
attachment, which should subscribe them (probably via a confirmation
dialog box).

Another example would be a link on a web page -- eg. Mantara might use
such a file to advertise the "elvin-support" channel.

I played briefly with such a setup before the 2001 workshop, and it
was very nice (if I do say so myself).  I couldn't convince anyone
else at the time though :-/

  Matthew> Short of embedding the actual key in the invite, which
  Matthew> would be pointless unless we already have a secure group to
  Matthew> use, the use of key names is the only way I can think of
  Matthew> (I'm assuming that using unique key names is the best way
  Matthew> to manage otherwise anonymous chunks of data).

Well ... maybe?

If the receivers are likely to already have a copy of the key, then
some sort of unique identifier is good.  But "unique identifier" and
"user friendly name" should probably be different things?

In the case where the receiver doesn't already have the key, and the
use of an existing, secure Elvin channel to deliver it doesn't exist,
then you're left with other means: a PKI, HTTP(S), email, sneakernet,
SMS, voice, etc.

This is where Jinx tried to help -- if you can send a message, with
deliver_insecure set false, and including the known public keys of all
intended receivers, you can send the key inline ...

I'm fairly dubious about using "David's Key" as a suitable identifier
because of the potential for collisions.



Also, it'd be nice to specify a file extension while we're at it, so
you can get suitable icons for such files in file manager apps, etc.
The "tt" prefix is kinda taken by TrueType, so "tts" seems likely to
be collision-prone -- any other suggestions?


  >>  Did you see Ted's recent release of xtickertape-2.0rc1 ?

  Matthew> I did, but I assumed this was a fairly minor bug-fix
  Matthew> release? Not sure why I assumed that, except that I get the
  Matthew> impression Ted's not doing much active development of
  Matthew> xtickertape right now.

I guess it wasn't a major release, but it brought it up to spec with
latest v3 rules, added the ability to reload your keys file without
restarting and added the use of SIGHUP to cause a reload of all config
files.  Fairly major improvements albeit not especially visible ones.





d