#social 2017-11-30
2017-11-30 UTC
timbl, tantek and rowan joined the channel
xmpp-social and tantek joined the channel
# 
Chocobozzz puckipedia: after thinking, you're probably right: a video channel should be an actor. So a user send a CREATE activity, and the video channel announces it so platforms that don't support channels just work out of box. Moreover people would have the choice between follow the user or follow a specific channel (like youtube btw).
# puckipedia :P
# Chocobozzz just miss a parent notion for actors in AP but a custom "owner" attribute to the actor should be okay
# puckipedia I would use attributedTo for that
# Chocobozzz good idea!
# Chocobozzz thank you very muck puckipedia. I just ping cwebber2 in case he disagrees
# Chocobozzz much*
timbl, rowan and sandro joined the channel
rowan joined the channel
# Chocobozzz okay thanks cwebber2, I think it will just be a Group actor, because in the future we could imagine that a channel is shared by multiple users
# Chocobozzz (ie multiple users could upload video in it)
# saranix how to mark up an encrypted payload?
# saranix http://manu.sporny.org/2013/lds-vs-jose/ mentions @type EncryptedMessage2012 -- but the ld signatures spec does not mention it (why is that hosted on github and not w3.org?)
# saranix hubzilla uses Salmon but I don't like Salmon :-P I mean interop is the ultimate goal so eventually I'll probably support both but I don't want to make it my default
# saranix even though that post argues against it, and how much simpler?
# saranix it's definitely simpler, and the linked blog post definitely argues that it's simpler in length... and manu is the CEO isn't he?
# saranix scratches head
# dlongley saranix: the differences are much more pronounced with signatures than with encryption (between the JOSE approach and the LDS approach)
# dlongley with encryption, the LDS approach we were looking at back in 2012 made key discovery and semantics simpler/easier ... and we also enforced encryption suites more tightly for both simplicity and because algorithmic agility can be a detriment to security
# dlongley those are the main differences... but we didn't see a lot of uptake on EncryptedMessage2012 ... and we don't really use it very much ourselves (we don't use really use JOSE either), we have stronger needs for signatures than we do encryption of message payloads... should a stronger need arise we'd explore the options again, but if JWE does what you need, it's not *that* different, it is mostly lacking in a key discovery protocol
# dlongley but someone could standardize how to do that using "linked data web keys"
# dlongley with the existing jku and kid fields in whatever way is appropriate
# saranix I definitely prefer EncryptedMessage2012. JWE is way too verbose for starters
# dlongley well, i agree that it's much simpler.
# dlongley JWE tries to do everything ... which can actually be a detriment to security.
# dlongley perhaps defining a particular profile of JWE and how to use it with linked data web keys would be a good spec.
# dlongley i imagine that's the direction Digital Bazaar would head in should we find a strong need for encrypted message interop
timbl, rowan and rowan_ joined the channel