#social 2018-12-21
2018-12-21 UTC
aaronpk joined the channel
# 
rialtate[m] I can't seem to find anywhere the "type" attribute is defined. Are there any rules for what this string can be? (I mean for extension object types of course)
# rialtate[m] Meaning acceptable chars, etc
# rialtate[m] I assume there must be some restrictions because context mapping ("foo:whatever") has to follow the : format
xmpp-social joined the channel
# JasonRobinson[m] @rialtate:matrix.org: as long as your document is proper json there should be no restrictions? Unless I misunderstood the question sorry
# rialtate[m] Json-ld has about 6 chapters on the subject and about all I can grok is that colons are indeed handled specially... But if I understand correctly then by using a context map explicitly I can have an IRI with colons in it (after an anchor perhaps) but then it might still need to be % escaped. Probably better just to avoid colon altogether
# Chocobozzz Hello everyone, i would like to implement playlists in peertube and i would like to have some feedbacks regarding how i imagine to represent them in ap voc. I plan to use the "Collection" object https://www.w3.org/TR/activitystreams-vocabulary/#dfn-collection but I'm not sure how to specify the objects (contained in the playlist) position
# Chocobozzz do you have some ideas? (or know an existing ap software that implements playlists?)
# rialtate[m] Chocobozzz: https://www.w3.org/TR/activitystreams-vocabulary/#dfn-audio
# Chocobozzz rialtate[m]: i'm sorry i don't understand
# rialtate[m] Chocobozzz: a Collection of Audio objects
# rialtate[m] Sorry you asked position... OrderedCollection
# rialtate[m] There is also the Listen activity
# Chocobozzz rialtate[m]: yes but in https://www.w3.org/TR/activitypub/#collections it is said "An OrderedCollection MUST be presented consistently in reverse chronological order."
# Chocobozzz a playlist is not ordered chronologically
# rialtate[m] Oh yeah. I've always thought that rule is dumb
# Chocobozzz or maybe it concerns only the collections presented in the document (outbox, followers etc)
# rialtate[m] Yeah reading that it seems to be specific to ActivityPub OrderedCollections defined in that section, although it could definitely be worded better
# Chocobozzz Okay thanks rialtate[m]. But if i use ordered collections, I think I should add a "position" field in the Add activity https://www.w3.org/TR/activitypub/#add-activity-outbox
# Chocobozzz and for reorders, I would just have to "Remove" the entry that is moved, and "Add" to its new position
# rialtate[m] Move activity? I could swear there was a before and after property but I guess not. I think that would be cleaner though
# Chocobozzz A Create activity with the Move object? (https://www.w3.org/TR/activitystreams-vocabulary/#dfn-move) it's a good idea!
# Chocobozzz But I think the purpose of this Move is to move an object from a collection to another collection
# rialtate[m] Huh? No Move is an Activity so no Create
# rialtate[m] Origin and Target don't *have* to be different collections... Not if you add the position or before/after properties
# rialtate[m] Technically they don't even have to be collections. You could Move a Page to a different url for example
# Chocobozzz Okay! For the Move in Create, in fact I thought we were supposed encapsulate non listed activities in https://www.w3.org/TR/activitypub/#server-to-server-interactions in a Create activity
# rialtate[m] So maybe even like
{ type:Move, origin: { position:1 }, target: { position: 5 } }# rialtate[m] Lol not 100% sure thats valid
# rialtate[m] What part says wrapping it? I don't see it
# Chocobozzz I cannot find it, you must be right. There is no reason we cannot use directly AS activities since AP extends it
# Chocobozzz I have to change my "View" and "Dislike" implementations then
# rialtate[m] Numbering with just position might be ambiguous though. Complete(r) object:
{ type:Move, object: uniqid, origin: { id:collection1, position:3 }, target: { id:collection1, after:othersongid } }# Chocobozzz nice, but I don't think we need the position in origin since the reveiver should know where the object is
# Chocobozzz receiver*
# rialtate[m] True
# rialtate[m] It might help for making sure activities processed out of order don't go haywire, that was my instinct anyway
# Chocobozzz And if position might be ambiguous, maybe I should use "after" in the Add activity too:
{ type: Add, object: ID, actor: ID, target: { id: collection1, after: othervideoId } (if no "after", it means we add the video inside an empty playlist)# rialtate[m] I suppose that's why Updates require the complete object. Come to think of it, playlists are short enough collections that sending an Update with the new ordering might be a better way to go anyway
# Chocobozzz it was indeed also a solution, because if a remote instance does not receive just 1 Add or Move, it could mess up the whole playlist
# rialtate[m] The spec sorely needs object versioning, or some kind of directed graph
# Chocobozzz an update seems to be more robust and simpler
# rialtate[m] Without versioning multiple actors doing updates and clock slew, all bets are off :)
# Chocobozzz yep :/
# rialtate[m] I suppose the authoritative server could make some kind of version number in the fragment be a signifier and then the remote implementations can be sort of naive while it deconflicts according to the owner's policies
# rialtate[m] Might work :-p
# Chocobozzz Yep sure, like an "updated date". Then the receiver does not process data where the date is < of its last update date
# rialtate[m] If they are too naive they might think the fragment signifies a unique document, and if you did the updated date thing as a field, in order for signatures to work it would have to be the remote time that would still suffer from clock sync :(
# Chocobozzz right
# rialtate[m] Seems to be a recurring theme with this protocol that there are a ton of ways to represent things that all have different problems and no "good" way to represent certain things, well most things, other than basic microblogging, and even that has a ton of issues :/
# rialtate[m] Hmm... Maybe clock sync isn't such a problem if the "current" time is in the http sig/header...
# rialtate[m] I don't remember if that's capable of microsecond resolution though.. Maybe not
# rialtate[m] Even with microseconds sync would be ok but slew still a problem sigh
ben_thatmust joined the channel
# sknebel vasilakisfil: just saw your questions about microformats etc: #indieweb-dev on Freenode is a better place for those
vitalyster, jdormit, distopico, KjetilK, raucao, edsu, puck, rhiaro, martijnvdven, nightpool[m], erincandescent, zauberstuhl[m], csarven, pantherse and decentral1se joined the channel
# dansup Chocobozzz: I think FunkWhale might have implemented this already
decentral1se joined the channel