#social 2017-07-17
2017-07-17 UTC
saranix joined the channel
# 
saranix in order for a AP client to be a useful thing, the client needs to be
# saranix ...able to tell the server a max page size, and also you SHOULD be
# saranix ... allowed to request an alternate order. I especially think " A
# saranix ...property which changes regularly, such a "last updated" timestamp,
# saranix ...should not be used. " is misguided. Some people would definitely want
# saranix ...their stream order like that, and more than that, the client should
# saranix ... be able to choose which field it is sorted by *and* also the depth of
# saranix ...expansion
# saranix hmm https://www.w3.org/TR/ldp-paging/ extends the Prefer (RFC7240) header... but the props they use don't easily transfer
# saranix max-member-count I support
# saranix *suppose
# saranix ahh ldp:pageSortCriterion
# saranix nah that's only informative server to client
# saranix so need to add sort-field and max-sub-expansion to Prefer.... If I start doing this in my implementation any chance others will copy?
# saranix I think this falls under getting the data... some clients may not be able to download the entire 4GB inbox in one GET (which the spec allows for)
# 
ajordan so I think that https://w3c.github.io/activitypub/#collections (I'm assuming that's what you're referring to?) should stay the same. better to present a stable interface that doesn't change all the time and let the client opt-in to less stable sorting, like a last modified field
# saranix yes... but I also disagree about ordering
# saranix I think the server should say which field it is ordering by, and the client can request an alternate field but is free to ignore the client's preference
# saranix without specifying, 4GB inboxes are possible, completely unpaged is allowed, and any page size is allowed, the server can do whatever and the client is just supposed to be able to handle it... I think that's way too open-ended
# saranix ok
# saranix go for it
# saranix note: https://w3c.github.io/activitypub/#collections does not specify an order, ActivityPub does
# saranix crap...wrong link
# saranix ignore me
# saranix https://www.w3.org/TR/activitystreams-core/#collections and ActivityPub makes it a thing, which I think is a mistake
# saranix it says MUST be in a certain order... as far as stable spec goes, does it break anyone's impl if it's changed to unspecified defaults to XXX instead?
# saranix yes but it also denies that last modified is a legitimate chronological
# saranix as a note
# saranix I don't think that's way too implementation specific actually
# saranix *do
# saranix that's why I advocate that the server tells specifically which field it sorted by, if it doesn't specify, one can assume backwards compatibility, then of course there is the Prefer request
# saranix huh?
# saranix Right now you're forcing an implementation that thinks of chronology a certain specific way....
# saranix If a client wants to sort by last modified, they have to fetch the entire collection to look for new ones... no matter what... if they are not allowed to choose
# saranix same argument how?
# saranix my solution provides backwards compatibility
# saranix the de jure default
# saranix how so? A client that doesn't request a sort order should be treated the same as one that expects the "old" sort order
# saranix the server will not sort by the last modified field unless asked by the client
# saranix and I suppose you think collapsing should be an extension too?
# ajordan in fact there are some things related to this on https://www.w3.org/wiki/ActivityPub_extensions#Possible_future_extensions (see "inbox search" at the bottom)
# saranix max-depth for object nesting, before using type:Link instead
# saranix you have :)
# saranix are you working on an AP impl?
# saranix does it have AP?
# saranix lol... no worries... just looking for servers to test with
# saranix not that I'm ready yet either... almost though
# saranix What do you think about this extension
{ type:Create, object:{Note}, target:{Collection} } ... sound reasonable?# saranix unrelated to other stuff we were talking about
# saranix What I'm thinking, is if an actor has an number of Streams listed on their actor obj, that a party might want to post directly to one of those collections... not quite sure how to request or convey permission though... maybe an Invite to the Collection? hrm...
# saranix since AP only has follow/following, what is the equiv of "post to XXX wall"? To:X, X-followers-collection? how does a person know if they have permission?
# saranix All my q are good :-)
# saranix I didn't know about Add... How does one know if they are allowed to Add?
# saranix The problem with Create then Add is it leaves the object out their in general and not confined to only the collection
# saranix there
# saranix but if you target the collection then it only goes there
# saranix There is an example in AS2 for MOVE using target in this fashion
# saranix Why not Create right to it?
# saranix Move kinda has a from
# saranix Add uses target
# saranix Create inherits properties from Activity, Activity contains target, it's not an abuse
# saranix looks like it's not even an extension now that I'm reading...
# saranix Completely new question... is there anything for the "read/unread" semantic like email inboxes?
# saranix https://www.w3.org/TR/activitystreams-vocabulary/#dfn-read but doesn't say that it changes the representation when fetching to indicate it changed status or is part of a ReadCollection or anything like that....
# saranix seems like it is more meant as a Read notify to the sender
# saranix like a return-receipt
# saranix or not even, the example show Sally reading a random blog post... just telling the world Today-I-Read
# saranix lol ok
# saranix I can't let it go... I'm in the zone :-)
# saranix For access control I've settled on (so far):
{ @context: ["https://www.w3.org/ns/activitystreams", {acl: "http://www.w3.org/ns/auth/acl"} ], Type:Person, streams: [ { type:Collection, "acl:mode": [ "acl:Read", "acl:Append" ] } ] }# saranix just listing the acl's that the current authenticated requester has
# saranix hmm AS defines Profile but is has no meaningful properties... is it expected to be full of foaf properties?
# saranix meh, an hcard would be better. What is the right mediaType for hcard?
astronouth7303 joined the channel
# saranix After thinking through a few usecases it might be better to acl: [ {},{] ] with a set of full acl triplesets (with subject assumed to be the viewer if omitted)
# saranix if only for consistency when applying it to other objects like Profile... to convey, for example: "you are allowed to share this profile with activitystreams#Public"
# saranix that's a pretty narrow usecase though. *sigh* still need some way to do it...
# saranix also thinking through an addressBook endpoint... that's why...
dwhly and xmpp-social joined the channel
# 
Loqi Benthatmustbeme made 1 edit to [[Socialwg/2017-07-18]] https://www.w3.org/wiki/index.php?diff=103778&oldid=103713
# xmpp-social [ajordan] Thanks ben_thatmustbeme
# 
ben_thatmustbeme no problem
# xmpp-social [ajordan] Good idea to bring that up
# xmpp-social [ajordan] I will say though this'll be one doozy of a call :/
# ben_thatmustbeme in terms of what?
# xmpp-social [ajordan] There's kind of a ridiculous amount of AP stuff, particularly with the changes to publicInbox we were discussing today
# xmpp-social [ajordan] Took us over 3 hours this afternoon
# ben_thatmustbeme we should probably get all other business out of the way first, i don't think there are any other major updates really
# ben_thatmustbeme other than that EME issue to bring up (also Diaspora had a similar response, though for different reasons)
# ben_thatmustbeme i also wanted to request an updated draft of jf2
# xmpp-social [ajordan] Ah neat
# xmpp-social [ajordan] I still haven't read the draft in its entirety, I'll try to do that before Tuesday
# xmpp-social [ajordan] The other thing is there's a bunch of agenda items we pushed from previous weeks
# xmpp-social [ajordan] Like bridging
# xmpp-social [ajordan] Implementation uptake is a blessing and a curse ;)
# Loqi Benthatmustbeme made 1 edit to [[Socialwg/2017-07-18]] https://www.w3.org/wiki/index.php?diff=103779&oldid=103778
# ben_thatmustbeme yeah, and pushed stuff is supposed to get first priority
# xmpp-social [ajordan] Smart
# xmpp-social [ajordan] Tbh earlier cwebber2 and I were discussing preemptively asking to extend the call
# ben_thatmustbeme there were things having starvation issues when we were just going by whatever seemed most important, so i pushed to move everything to be FIFO
# xmpp-social [ajordan] Yeah that's way better
# ben_thatmustbeme at the very least it would be good to mention it right up front
# xmpp-social [ajordan] Yep
# ben_thatmustbeme also might be good to write something up of all the changes made, if that makes sense
# ben_thatmustbeme i was going to say 'you are up late' but you are west coast aren't you?
# xmpp-social [ajordan] You mean on the agenda?
# ben_thatmustbeme or as a post and link to it on the agenda
# xmpp-social [ajordan] Yep! PST
# xmpp-social [ajordan] Yeah I'll do that; I made sure to capture everything in issues
# xmpp-social [ajordan] What timezone are you by the way?
# ben_thatmustbeme EST
# ben_thatmustbeme err EDT right now
# xmpp-social [ajordan] Neat
# xmpp-social [ajordan] So you're the one up late then ;)
# ben_thatmustbeme yep, 3 am server outage, so i woke up an hour ago
# ben_thatmustbeme have ram failing on the companies primary DB server
# xmpp-social [ajordan] Oh dang that's brutal
# xmpp-social [ajordan] Sorry to hear that
# ben_thatmustbeme eh, its okay, thankfully my body woke me up at 2 am
# ben_thatmustbeme rather than having to wake for my alarm at 2:45
# ben_thatmustbeme my subconscious is pretty good about getting my butt up when it needs to
# xmpp-social [ajordan] Ahh. That's nice
newton and timbl joined the channel
# Gargron about the discussion of sorting responses in client-to-server API, that's kind of why i'm not interested in a standard client-to-server API. every application *may* be different, s2s AP allows a youtube-type and an instagram-type and a mastodon-type platform to exist, but each of those presents content completely differently to the users, and making a standard c2s API for all of them would limit their abilities to be good applications, prevent innovative
# Gargron applications that weren't expected, and it puts a lot of onus on client-app developers
# puckipedia the c2s api is pretty much optional though
# puckipedia and alternately it explains how the side effects on e.g. liking an object work
timbl and newton joined the channel
# puckipedia https://puckipedia.com/social is my test account
# puckipedia Gargron: ^
# puckipedia cwebber2: and yeah, for not having to store entity data: maybe do e.g. https://example.com/object?like=12&by=123&signature=AAQAi8fjzshd_as-? :P
# puckipedia tries to use Kroeg to send a reply
# puckipedia welp it's catching the old mastodon activitypub stuff
newton and Gargron_ joined the channel
# Gargron_ yo
# ben_thatmustbeme is there a 'yo' instance of mastodon yet? :P
newton joined the channel
# saranix hmm... yeah, that mastodon reply in puckipedia page has a non-dereferencable (non-compliant) id https://www.w3.org/TR/activitypub/#obj-id
# puckipedia I know that
# puckipedia currently for non-AP posts I just put the inReplyTo manually
# saranix oh it came from non-AP?
# puckipedia the tag: one, yes
# puckipedia check the url
# saranix hmm... my parser still rejects it
# saranix I don't know if I want to write a work-around
# saranix since it's clearly non-compliant
# puckipedia I might just drop OStatus support once Mastodon has ActivityPub implemented
# Gargron_ yeah
# Gargron_ added test spec for account resolver https://github.com/tootsuite/mastodon/pull/4216/commits/4d933301fde7c1bd5bfbd3229688e8f70255161d PogChamp
# Gargron_ gotta fix how icon/image are serialized
# Gargron_ i dunno if publicKey should have some sort of pinning precaution
# Gargron_ on one hand, ppl keep losing databases and recreating users and stuff like that, and each time there is a genuine need to accept a new public key
# saranix yeah I brought up ttl last week I don't think anyone saw me :P
# Gargron_ in current mastodon setup, it stays pinned for a day
# Gargron_ and tbh... well, it means people have to wait for a day when they brick their account
# Gargron_ i guess there is no real reason not to accept updates to it, if it's delivered over TLS anyway
# saranix the flip side is, it's extremely expensive to keep fetching a key
# puckipedia alternatively, you could try to resolve a key if a signature fails to validate?
# puckipedia though maybe that should be rate limited
# Gargron_ puckipedia: talking about this line https://github.com/tootsuite/mastodon/pull/4216/files#diff-9ad66311219adfd749e084691c22eb5eR53 when we fetch an actor
# Gargron_ i mean i still need to add a special case for when it's not embedded and another http roundtrip is needed
# puckipedia maybe make a method resolve, that just passes the object through if it's a Hash, or else GETs it
# ben_thatmustbeme have seen some terrible user issues where an instance crashed in other networks and there is no path forward and just no one accepts the new key
# ben_thatmustbeme i thought the one-day thing was to mitigate issues when a host gets hacked temporarily
# ben_thatmustbeme or rather the URL gets taken i mean
# ben_thatmustbeme though the more i think about it, neither of those are good use cases
# ben_thatmustbeme its really only for man in the middle attacks huh
# 
cwebber2 saranix: Gargron_: https://web-payments.org/vocabs/security#expires
# puckipedia but what if the server's data is erased
# puckipedia and you restart, and someone recreates an existing account
# saranix I agree with canonical fallback in the case of verification fail (exactly once)
# saranix at leasted automated... a failqueue for admin intervention might be useful for weird edge cases
# puckipedia I would suggest trying max once a day after a verification fail
# ben_thatmustbeme puckipedia: or for that matter if ther server closes completely, DNS expires, and someone else takes it
# ben_thatmustbeme in theory they could pretend to be every user that was ever on that server
# saranix ben_thatmustbeme: that's actually a problem for this protocol. My protocol pairs user keys with the server software key to define a unique "user", specifically for that situation, but AP does not have software keys
# puckipedia hmmmmm
# saranix from a security standpoint, there should be a software key
# saranix the software is being entrusted with custody, but with no verificatio
# saranix n
# ben_thatmustbeme so i have heard a lot about this from one user on friendica who had this issue, his server crashed, lost his key, now none of his friends are getting any updates as they all see it as invalid sigs... they have to remove and re-add him
# ben_thatmustbeme one suggestion was to put it to the user and have a notification saying the reset
# ben_thatmustbeme but i'm guessing the remote user's info is stored server wide
# ben_thatmustbeme its a very interesting and messy problem
# saranix Another argument for a software endpoint: getting version information of who you are talking to for protocol ambiguities
# saranix I've decided. For my impl I will be adding a software attribute to the canonical actor object
{type:Actor, software: {type:Application, version:ver, publicKeyPem: software-key } }# saranix actually I think I'll reuse the "generator" attribute
# ben_thatmustbeme well, ideally it should be just the protocol version thats needed, but the software version can be useful for things outside of spec
# puckipedia generator?
# puckipedia at least, imo generator is close enough for the actor
# saranix it's more semantic... generator it is
# puckipedia like, this actor is [generated by/hosted by] this application/server/whatever
# Gargron_ a server key does not solve the described problem btw
# Gargron_ if the admin loses the db
# Gargron_ or even if the key is outside the db, as a flat file
# Gargron_ the key would get lost and the admin would regenerate it and you're back on square one
# Gargron_ imo the "somebody takes over the domain" is a social problem
# Gargron_ or maybe on the DNS level
# saranix if the admin loses the DB, there is nothing that can be done and no way to mitigate it. It's like losing your own key with no way to "reset" your password. You're screwed. You should've backed up, dummy.
# Gargron_ yeah but it's gonna happen
# Gargron_ it's happened
# Gargron_ many times
# Gargron_ you can't just tell them "well, the domain you bought is now worthless, you'll need to get a new domain"
# saranix I'm more concerned about someone buying reallypopulardomain.com and stealing all the users
# saranix yes, you can tell them that, because that's how domains work
# saranix we can't change how domains work, so we have to work within that
# Gargron_ i see it this way
# Gargron_ the key is used for verifying it's user from domain
# Gargron_ the *initial* key is also served from the domain, so if somebody takes it over, they're gonna serve their own key
# Gargron_ it's not used for verifying actual identity of the person behind the user account
# saranix I'm considering an E2Ekey for this purpose
# saranix it's authoritative on nomadicity (vis a vis Zot)
# Gargron_ an e2e key is cool but it's a separate layer imo
# Gargron_ i think im not gonna pin public keys in my code for now
# saranix Yeah I had a look a DIDs, they are overly complex...
# saranix I haven't found a fitting property to stuff the E2E key into yet...
# Gargron_ i mean, the publicKey can be an array i think
# puckipedia it can
# Gargron_ however i dunno how you want to symbolize whether a key is server-owned or e2e
# puckipedia does it matter?
# saranix yes, the E2E key is authoritative for server switches, key changes, etc, and the private part should never be shared with a third party
# saranix it's like your "email for password reset" of yore but with better controls and crypto
# saranix it will need a massive javascript UI, especially since WebID is dead WRT browser key generation
# saranix My old software uses client TLS for this purpose, but because of that deprecation, I have yet to replace it with a new UI
# Gargron_ nice
# saranix err... which spec talks about publicKey and publicKeyPem? I can't find them in AP or AS2 with a text search
# saranix hmmm
# saranix missing from that vocab is allowed usages of the key
# Gargron_ serverOwned vs userOwned param on keys, something like that, would be interesting
# Gargron_ i made my parser support publicKey URIs and proper Image objects vs URIs too: https://github.com/tootsuite/mastodon/pull/4216/commits/f0bc2b064bc0231bda188115bb0ee268b2bcd1e3
# saranix it's not a matter of who owns it, but what it's authorized to be used for. I have 3 uses defined explicitly -> signLocations (e.g. which servers are allowed to speak for this id), 'signTransportRekey' (e.g. allowed to change the transport key (the one attached directly to the actor) without having an https:// endpoint that matches, and E2E (encrypt payloads to be read only by receiver)
# saranix although I have to admit that E2E has some ambiguity WRT deviceid
# saranix still a WIP
# saranix server key allows authoritative user rekeys from within the same origin
# saranix has nothing to do with http sigs
# saranix well, I suppose it would be signing the rekey request somehow, haven't gotten that far
# Gargron_ puckipedia: huh so it's really "_:conversation" that's a weird key
# Gargron_ why not just "conversation"?
bblfish joined the channel
# Gargron_ okay..
# Gargron_ another question. i am working on FetchRemoteStatusService now.
# Gargron_ so i resolve a note URI, and it contains an attributedTo
# Gargron_ i intend to verify that the attributedTo URI and the note's own URI are on the same host
# Gargron_ reasonable?
# Gargron_ otherwise i'd be able to publish notes on behalf of someone else
# saranix I think you should just verify that the note fetched from it's canonical url matches
# saranix you can't be guaranteed that outbox.someprovider.com isn't also the same provider as coolinboxes.com
# saranix but if you fetch the canonical item and it's there, it's legit
# Gargron_ i am already fetching the note from its canonical url
# saranix then that should be sufficient?
# Gargron_ but it just says it's attributedTo some actor
# Gargron_ how do we know if that actor really did write it
# Gargron_ yeah without LDS
# Gargron_ incoming requests are signed that way for sure
# Gargron_ but i just wanna resolve a status by its URI
# Gargron_ "pull"
# Gargron_ don't have signatures there
# Gargron_ that's where LDS would be useful
# saranix it's looking more and more like we need to mandate LDS, solves a lot of problems
# Gargron_ all i can think of to sidestep is the host comparison
# Gargron_ because you can be reasonably sure a host cannot impersonate itself
# Gargron_ i'd rather not oauth like this
# Gargron_ i think of oauth as client-to-server
# Gargron_ yeah im just gonna compare hosts for now
# saranix since the origin is spitting out the publickey to the actor anyway, they can just place any false key there, so a canonical fetch is defacto assurance
# saranix https anyway
# saranix by comparing hosts you're disallowing legitimate use cases/server architectures
# saranix Also, what if I'm allowed to post to someone else's collection on another server
# saranix author won't be same origin
# Gargron_ saranix i am not sure you see the problem here. let's say i publish https://example.com/notes/foo, which will contain
{ content: "Dogs are bad", attributedTo: "https://saranix.com/me" }# Gargron_ https://saranix.com/me has never written such a thing
# Gargron_ then some other user tries resolving https://example.com/notes/foo, through search, or other means
# saranix ahh... yes... I guess only possible with ldsig then... dang
# Gargron_ ye
# Gargron_ host comparison would be a monkey patch for now
# Gargron_ afaik http signatures are for *requests*, not *responses*
timbl joined the channel
# puckipedia <Gargron_> why not just "conversation"? <- to be 100% clear that it's kinda hacky
# puckipedia cwebber2: tbh it's only used for internal stuffs
# puckipedia to ensure I can do 100% lossless OStatus<->ActivityPub
# puckipedia I use blank nodes for those indicators, that you should not assume it exists
# Gargron_ didnt realize what exact problems they would solve before i started implementing
# Gargron_ but reason was: Too Hard
# 
jaywink this is how diaspora does it just for fyi: https://diaspora.github.io/diaspora_federation/federation/magicsig.html .. based on https://cdn.rawgit.com/salmon-protocol/salmon-protocol/master/draft-panzer-magicsig-01.html
# jaywink what about JWS? where they ever considered for signing the payload? (https://tools.ietf.org/html/rfc7515). At least it's a standard, but I've always found the JW set looking really heavy and scary :)
# saranix JOSE is very open-ended and loose. Even https://web-payments.org/vocabs/security talks about LDsigs being only implementing the RS256 varient
# saranix keeping in mind that all 6 or 7 of these are all "draft" standards, either abandoned after creation 2-3 years ago, or just drafted months ago
bwn and timbl joined the channel
# Gargron_ how tf would you "normalize" the to-be-signed json document (for LDS)
# Gargron_ i mean for goodness sake can't you just take the json output as a string and sign that
# Gargron_ all you need to do for verification is take the very same string of json minus the signature itself
# saranix lol you sound like me last week
# saranix The specs go in circles but never say how
# saranix I came to the conclusion, reading between the lines, that "normalize" means, "make sure all required parameters exist"
# puckipedia the normalization is, afaik, basically turning the JSON-LD into a specific form of RDF, then hash that, then that is signed
# puckipedia at least, I'm not 100% sure as the spec is mostly for people that want to implement it and also for masochists (not even kidding, that's what it says)
# saranix I think that is the only sticking point for us getting ld-sigs done, and if we all have some inclination of doing ldsigs, let's just decide ourselves on a way that we all agree on
# saranix at least for now, so we aren't stuck
# saranix doesn't have to be perfect
# saranix \o/
# puckipedia so I think the only thing the spec will have to include is the use of publicKey
# Gargron_ i am for just taking the json string in whatever form
# Gargron_ without extra processing it's gonna be in the same form/order on input as well as output
# Gargron_ (while it's a string i mean)
# saranix whitespace
# Gargron_ nah whitespace won't change if it's a string
# puckipedia PHP escapes slashes inside string values in JSON
# Gargron_ ok tbh i don't know how to remove the signature subsection of it while it's a string tho
# Gargron_ this spec is effed up
# saranix puckipedia: json_encode($string, JSON_UNESCAPEDSLASHES|JSON_PRETTY_PRINT); <-- mirrors Kroeg
# Gargron_ i hope some poor soul writes a ruby library for it so i dont have to
# jaywink are we talking about this? https://w3c-dvcg.github.io/ld-signatures/#signature-algorithm
# puckipedia jaywink: I think the biggest point is the canonicalization algorithm
# Gargron_ yes step 2
# puckipedia Gargron_: the point is that JSON-LD signatures are made to be able to sign any JSON-LD document
# Gargron_ it's like "step 2: solve P=NP. step 3: .."
# puckipedia and any JSON-LD document can be represented in many ways
# saranix lol gargron
# puckipedia Gargron_: eh. it's doable. it's got an exact list of things to do
# puckipedia the point is that JSON-LD
{ "@context": "http://www.w3.org/ns/activitystreams", "actor": "https://example.com/actor" }# puckipedia is equal to JSON-LD [
{ "https://www.w3.org/ns/activitystreams#actor": [ { "@id": "https://example.com/actor" } ] } ]# Gargron_ i wonder if http sigs can be stuck into a http response
# puckipedia probably not too difficult to do
# puckipedia hm, maybe it is
# Gargron_ would need to implement Digest header to actually digest the body of the response and sign it
# Gargron_ but it would be much simpler than this LDS stuff
# Gargron_ because you only need to care about the whole body, verbatim. no canonicalization
# Gargron_ no parsing, no removing signature
# Gargron_ "1.2. Using Signatures in HTTP Responses"
# Gargron_ it's not further specified
# Gargron_ cwebber2: maybe you could ask your friends about that
# saranix reading https://json-ld.github.io/normalization/spec -- It talks an awful lot about blank nodes... We don't have those, do we?
# saranix everything has an @id
# puckipedia not true
# saranix according to this, we should order by @id
# puckipedia @id can be null
# saranix not server-server it can't
# puckipedia "An ID explicitly specified as the JSON null object, which implies an anonymous object (a part of its parent context)"
# saranix and if you are doing client-server there is no reordering because it is one object
# puckipedia just for activities it must have IDs, except if it is transient
# saranix in the case there is no ID, the algo says to map each one to a black node _:a to _:z and sort them by their SHA256 hash
# saranix blank
# saranix although I must admit I don't understand this blank node stuff
# puckipedia a blank node is _:asdf
# puckipedia an id of*
# puckipedia and basically blank IDs are used when it doesn't matter what ID the object has outside the context of the document
# saranix "In short, it is a node in a graph that is neither an IRI nor a literal"
# Gargron i intend to use blank IDs for binary privately-targeted events such as follow/unfollow, like/unlike (because those will not appear in any collections)
# saranix blank face
# Gargron anyway, that's all a bit too bothersome. at least i made some progress today
# Gargron i need to refactor a good chunk of code to make any further progress so i'm a bit frustrated
# Gargron i was thinking how to fit AP data with old OStatus data in the db: https://github.com/tootsuite/mastodon/pull/3827#issuecomment-315653890
# puckipedia saranix: so an IRI id, is basically most URIs. A literal is basically any possible value. And a blank node starts with "_:"
# saranix But blank nodes DO have a value...
# puckipedia _:asdf is a blank node, not a literal
# saranix but "_:asdf":"somehash" IS a literal
# puckipedia I mean _:asdf is a blank node called "Asdf"
# jaywink https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 (just looking around for simpler options)
# puckipedia "asdf"*
# puckipedia a literal can also be integers, a dateTime, etc
# saranix https://json-ld.github.io/normalization/spec#blank-node-identifier-issuer-state "issued identifiers list: A list that tracks previously issued... also tracks the existing identifier that triggered the issuance, to prevent issuing more than one new identifier per existing identifier, and to allow blank nodes to be reassigned identifiers some time after issuance"
# saranix I have no idea what that gobbledygook means
# puckipedia blank nodes are used when you don't want to give a node a permanent ID, but you do want to refer to it within the document
# puckipedia e.g.
{"id": "https://example.com", "type": "Create", "object": {"id": "_:thing", "type": "Actor"}, "actor": "_:thing"}# puckipedia _:thing is not referrable outside this document. but it is referenced inside the document
# jaywink here is the Matrix way: https://matrix.org/docs/spec/appendices.html#canonical-json
# puckipedia yes but matrix doesn't use JSON-LD
# puckipedia :P
# puckipedia I think once we get extensions that use JSON-LD contexts it starts getting complicated
timbl joined the channel
# puckipedia and e.g. in AS2, "conversation": "asdf" and "_:conversation": "" are equal, technically, as long as conversation isn't defined in AS2 spec
# puckipedia ehm, "_:conversation": "asdf"
# saranix I'm in favor of https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 -- no sorting. The signature is only valid for the object AS-IS
# puckipedia saranix: please sort. JSON objects aren't defined to have an order?
# saranix puckipedia: only matters if you want to try to reconstruct an object, this way, we never do. Only verify signatures as if the object was a blob
# saranix it sucks, but is it really any different than storing the message content as an opaque b64 string?
# saranix or PEM
# saranix for that matter
# Gargron cwebber2: sorry i dont think you need to store the blob-as-is unless you want to repost the original thing again, for me LDS is important in verifying content supposedly-from-the-origin
# Gargron that was today
# Gargron and comparing hosts is a temporary solution
# Gargron im feeling jaded, i wanna make a decision on the db structure stuff for accounts but nobody gives me feedback on that
# Gargron i mean, your server shouldnt even show that to you if it's not verifyably true
# 
aaronpk bridgy being the biggest example of this: https://media.aaronpk.com/Screen-Shot-2017-07-17-13-43-39.png
# Gargron putting the onus on users to check things that can and should be verified cryptographically is aiming the system at only engineers
# Gargron and even engineers i bet wouldn't want that kinda UX
# Gargron ummmmm no
# Gargron it would be deployed in a network with over 700,000 accounts
# Gargron most of who aren't engineers or IT people
# Gargron so no, not premature
# puckipedia so just an origin check?
# Gargron *allowing* is not the issue here lol
# Gargron like im not gonna write software with a function to forge messages
# Gargron it's more of a "releasing software with a gaping vulnerability"
# Gargron that's why we are talking about it here
# Gargron i need to be able to pull down a status by URI most importantly for thread resolving, e.g. i receive msg from server A which responses to msg from server B which i do not have in db yet
# Gargron *responds
# Gargron an origin check should be ok
# Gargron somebody raised the point that actor JSON, and notes JSON do not *have* to be on same domain
# Gargron i dont necessarily see a use case for it being that way tbh
# puckipedia I don't think it's going to come up very often full stop?
# puckipedia I think 'inbox being on another server' will be more often than that
# saranix Anyone see any problems with this: https://pastebin.com/FvFujcQm ... The signature blob has to be stored as a text blob. The order of the "fields" array is used to reconstruct the obj to verify the signature. Sound good?
# Gargron not subdomain users but custom domain users (foo.org pointing to instance that normally runs as bar.org, which for that domain pretends it's single-user)
# Gargron in that use case all URLs would use the custom domain too
# Gargron i think
# Gargron i haven't mapped it all out
# puckipedia Gargron: well, I would guess except for the shared inbox
# puckipedia as it'd be shared by all users on that server in Mastodon's case
# saranix err https://pastebin.com/ew5iSxa6
# puckipedia because now I can fake-add a cc to it
# saranix It was argued that there was a need for extensions, adding fields, etc
# saranix puckipedia: no you can't
# saranix puckipedia: you add a fake cc, the sig doesn't include cc, the sig fails
# puckipedia why not just... sort them?
# saranix This is a solution to the normalization problem
# Gargron lmao
# saranix it was described as intractible
# saranix existing signatures in social network protocols work this way, signing certain fields
# saranix any other fields are considered "untrustworthy"
# saranix DKIM works this way
# saranix HTTP sigs works this way
# puckipedia well, sort them, turn the short values into full IRIs as per JSON-LD spec, then write a string describing the contents. oh wait
# saranix I'm saying we don't need their complex algorithm for our non-complex protocol
# saranix cwebber2: My proposal assumes whitespace removal. But you still need to list the fields to ensure no one tries to sneak extra ones in. Since you are already listing them, you might as well allow the order to be important
# puckipedia saranix: so if you sneak in another one, the signature will change!
# Gargron i dont have anyone to discuss db design with rn and it is driving me up the wall :weary:
# saranix cwebber2: you don't store the sig values as a hashmap, you store the json blob of the sig
# Gargron thats why i cant even just ask on masto
# Gargron there's like 3 people who can form an informed opinion
# puckipedia Gargron: hm, what were you thinking about?
# saranix puckipedia: no, how?
# Gargron i have a bunch of fields in accounts table which are used for ostatus. feed url, salmon url, hub url.
# Gargron now i need to add some AP fields, outbox url, inbox url, sharedInbox url
# saranix aaronpk: if you have a sub-object, it must be an IRI
# puckipedia saranix: beacuse the JSON representation of the object changes, so the signature changes
# puckipedia saranix: ooooh, well, "endpoints"
# Gargron i was thinking they kinda map onto each other if i rename them and add an account type enum (ostatus|activitypub)
# puckipedia Gargron: I think that'd be fine. My "inbox" is also the target for Salmon and WebSub :P
# Gargron i need to add an extra field for followers_url so i can handle the addressing
# saranix aaronpk: In this way, the person is only signing their OWN object, it is assumed that each other object well have their own signatures attributed to *their* authors
# Gargron i was also considering caching the totalItems values from followers/following/outbox collections so i could present that to the user maybe
# puckipedia Gargron: how often would you refresh those values?
# saranix aaronpk: scratch that, subobject should be allowed to be signed as well. So you know when I "liked" a note that said "that's awesome", that is the version I was liking
# Gargron good point, it would take extra effort to refresh them on tim
# Gargron good point, it would take extra effort to refresh them on time
# puckipedia saranix: so now someone does Update: object
# puckipedia should that like be undone?
# puckipedia if a user changes their display name, should their followers all be removed? because the follow isn't valid anymore?
# saranix aaronpk: so fields: [ "to","content","published",
{"parentobj": ["content"]} ] or something# puckipedia so now you have an object in JSON-LD that doesn't have an ID
# saranix puckipedia: the like is only valid for the old version. It isn't undone, but it's up to the UI to display this distinction (or not). It's a simple matter of fact in reality, so no use arguing over it :)
# saranix What is all this talk of "spoof the rest". If the fields are not signed, they are not signed. Discard them like whitespace. Not rocket science
# puckipedia saranix: .. okay, imagine this
# puckipedia user A creates an object
# puckipedia user B receives that object and likes it
# puckipedia but at the same time that user B likes it, user A updates it because it contained a typo
# puckipedia and inbetween the liking and user A receiving the like, the object has thus changed
# saranix puckipedia: like I said, we are talking about reality here. The fact is, pre-update is not what I signed.
# saranix puckipedia: it's up to the UI to explain the facts to the user
# saranix ""user A" liked a previous version of this"
# saranix or whatever
# saranix You don't have to
# saranix Only if you want the sig to still be meaningful
# puckipedia does that mean you assume that if the signature fails for the inner object, that it was a previous one?
# Gargron once you verify an object, it's in your db...
# Gargron why should future updates matter?
# Gargron i feel like a lot of this discussion is influenced by a not-relational db design
# saranix not sure backstore really matters
# saranix But yes, you can just say that "version ABCDEF" was signed by User B. And not have access to that original version anymore
# saranix to your own users
# Gargron as cwebber2 said, it does affect how you view the protocol a lot
# saranix having already verified the sig and stored it
# puckipedia saranix: how do you know that object wasn't maliciously edited to show the wrong content, then signed with that wrong content?
# saranix puckipedia: what do you mean?
# Gargron yes but not in the way that you need to verify old content *again*
# Gargron you only need to verify the *update*
# saranix gargon: right
# puckipedia saranix: you post a
{type: Note, content: I am awesome, actor: saranix, id: saranixIsAwesome}. Then I send a {type: Like, object: {type: Note, content: I am horrible, actor: saranix, id: saranixIsAwesome}, signature: [properly signed]}# puckipedia it validates the signature and sees it's fine. but it doesn't know for certain what an older version of the note says
# puckipedia Gargron: so are there any Mastodon servers that have statuses that show differently on different servers
# puckipedia like, someone makes a status that shows which instance you're on or something
# saranix puckipedia: if the published date is not one of the signed fields, then that is an assurance that the author left out. if it's not assured, then it isn't
# Gargron i dunno what you mean exactly but probably not
# saranix puckipedia: if the content is not signed, then it isn't :-)
# saranix puckipedia: If my signature only points to an IRI, then the only assurance you have is that I liked *some version* of that IRI
# puckipedia hm. oulipo.social doesn't edit incoming statuses
# puckipedia jaywink: if you were to sign something, it'd be always. so e.g. example.com/user/puckipedia would have the signature too
# saranix puckipedia: if, however, I signed a specific version, then it is up to the UI to convey that meaninfully
# puckipedia so actually I just thought of this
# puckipedia and aactually JSON-LD signatures already has this
# puckipedia if you sign an object with `object` being a URI, it signs the uri. sign an object with `object` being an embedded object, and it signs it with the embedded object
# saranix puckipedia: that's what I've been saying :)
# puckipedia saranix: I mean without having a list that basically says "these things are signed"
# puckipedia just sign all of it all the time
# saranix puckipedia: then we have the P=NP signing algo again
# puckipedia oh wow
# saranix also object reconstruction, which is not relational compatible
# saranix limiting fields removes ambiguity *and* allows different impl to offer different assurances for their particular usecase
# saranix s/limiting/naming
# puckipedia :P
# cwebber2 http://dustycloud.org/blog/an-even-more-distributed-activitypub/ well I guess I already blogged bout it :)
# puckipedia aha, I kinda imagined what that'd be based on the title hehe
# saranix cringes every time someone mentions "blockchain" or "merkle" or "DAG"
# saranix It seems there's 2 camps: the hype camp, and the math nerd camp. Not much in between but tumbleweeds...
# saranix lol
# saranix I think it's a translation problem, but yeah, that happens a lot with maths
timbl joined the channel
# puckipedia -> bed
newton joined the channel