[ticker-dev] Ticker group "invitation" attachments

[Phillips, Matthew]

[David]
> -->"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 ...

Eeeek! Too complex [small popping sound as brain implodes] ;) I was kind of just seeing this as a natural complement to the key file format.

>   >> 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).

Good point. Although I tend to re-use keys and so, once they're exchanged, an invitation that refers to them would still be useful. But being able to optionally embed the key(s) with the invitation would make more sense - I didn't go there because the name/value format isn't composable. Dare I mention XML? ;)

> 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?

Good point. An alternative would be to just treat the SHA1 of a the key as its ID? (or the key itself for shared keys). I know this isn't fullproof.

> 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 ...

You can do that with Sticker too btw.

> 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?

That would make sense, but I certainly wasn't planning to actually implement anything like that :/ Managing registration of file extensions is just Too Hard (tm). For now I'm just allowing copying of key text from anywhere and allowing it to be pasted into Sticker.

>   >>  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.

V3 support is good. Now all we need is Aquatik to do v3 (fully ;) and we can drop the v1/v3 hybrid ticker messages.

Matthew.