#social 2017-11-17
2017-11-17 UTC
rowan joined the channel
# 
bengo puckipedia what about this one? Still got same response from your inbox https://distbin.bengo.is/activities/e6b010d5-b3a5-4eb0-b998-302309efde74
# bengo "distbin:activityPubDeliveryFailures": [
# bengo {
# bengo "name": "DeliveryErrorResponse",
# bengo "message": "401 response from https://puckipedia.com/inbox\nResponse Body:\nSequence contains no elements"
# bengo }
# bengo ],
timbl joined the channel
# distopico Hi, other question, I know the authentication is not part of activityPub specifications
# distopico How determine the authentication type between servers, how know if is oauth or oauth2
bengo joined the channel
# bengo distopico the best solution I've seen for authn system discovery is https://openid.net/specs/openid-connect-discovery-1_0.html
# distopico ok, looks good
cdchapman, xmpp-social, bengo, timbl, bwn, rowan and timbl_ joined the channel
bengo and rowan joined the channel
# puckipedia bengo: ehm I tried to import the entity into my DB
# puckipedia it stack overflowed
# puckipedia https://distbin.bengo.is/activities/e6b010d5-b3a5-4eb0-b998-302309efde74 <- this one
# puckipedia bengo: I think it's because you're not defining distbin in the context
# puckipedia bengo: and the other issue is probably that your ID for the as:object is still an uuid
# puckipedia not sure
# bengo puckipedia roger
dlehn and cdchapman joined the channel
# puckipedia wondering why Kroeg stack overflows on triple->non-triple serialization
# puckipedia ... I can guess, though
# puckipedia I guessed w rong
# puckipedia if you guessed "as:url is pointing to itself", then you were right
# puckipedia I'm not sure why this isn't caught
# puckipedia probably because it's the root object which points to itself
# puckipedia still stack overflows wtf
# puckipedia ajordan: oh no the actual issue is way worse
# puckipedia I got bored and implemented my own triple ->
{internal AS2 object / triple store}# puckipedia insetad of just wrapping jsonld-api's triple -> json-ld
# puckipedia what happened is that it basically retrieves a graph from the DB, turns every object into an ASObject, but also replaces references to IDs in the graph (all but one being blank nodes) to their respective object
# puckipedia this can, of course, create cyclical references
# puckipedia it works now :D
# puckipedia bengo: https://distbin.bengo.is/activities/94cb0314-9ea7-428a-8be2-f3b041360164
# puckipedia you should probably do cc the attributedTo of the object :P
# puckipedia bengo: ahaha. the issue is that t here's no actor. also, HTTP signatures
# bengo puckipedia sweet! I think my page there is only used to being inReplyTo activities, not the Note
# bengo so I can work on that
# bengo puckipedia do you have it so that replies delivered to your inbox would render here? https://puckipedia.com/status/85d238d7/note
# puckipedia not yet. wouldn't be a lot of work
# bengo puckipedia nvm I'm not even delivering to you all the way yet. "distbin:activityPubDeliveryFailures": [
# bengo {
# bengo "name": "Error",
# bengo "message": "Could not determine ActivityPub inbox from $
{contentType} response"# bengo }
# bengo ],
# puckipedia bengo: that was inReplyTo the note
# puckipedia bengo: ah. I don't actually put things in the replies collection
# puckipedia this is an issue
# bengo puckipedia ah I am not doing profile discovery for the resource that it's inReplyTo. Just looking for an inbox right on the ojbect. I'll add that now.
# puckipedia bengo: my advice is to check for attributedTo on the note
# puckipedia then add that to cc
timbl joined the channel
# puckipedia bengo: okay, I store replies now
# bengo puckipedia nice. working on addressing .attributedTo
timbl_ joined the channel
# 
cwebber2 rhiaro: csarven: "some hard-core ontological questions" http://www.qwantz.com/index.php?comic=3215
# rowan has anybody got time to help me with some federation debugging? i'm missing something between webfinger and account information
# puckipedia rowan: hm, AP?
# rowan yep
# puckipedia go on ;P
# rowan when i search for an account from mastodon it doesn't take the self link from webfinger, and i'm not sure what i'm sending wrong; i'm returning an application/ld+json; etcetc (or xrd/xml if requested)
# rowan getting error 422
# puckipedia right. can you link me the server and the account?
# rowan https://populator.smilodon.social acct:roo@populator.smilodon.social
# puckipedia spins up local Mastodon
# puckipedia rowan: ehm what
# rowan uh oh
# puckipedia Webfinger query for roo@populator.smilodon.social unsuccessful: Invalid response mime type: {'date': 'fri, 17 nov 2017 21:49:23 gmt', 'signature': 'keyid="https://populator.smilodon.social/api/roo#main-key",algorithm="rsa-sha256",signature="uhwhsuenhqvh2ljaq/gwq+hespjqnk3hhzkbmk3ugqpvh90hps8vpuhirv4a3djewq6kifzjdbtvvdtqghgebg=="', 'content-type': 'application/ld+json
# puckipedia rowan: your content-type, lol
# rowan oh shit damn it
# puckipedia love too write code
# rowan could you try again? should be better now ???
# puckipedia right, it doesn't like ld+json, you want jrd/xrd
# rowan aha
# rowan okay
# rowan doesn't the AP spec say that it should be ld+json?
# puckipedia that's for AP objects
# puckipedia this isn't an AP object :P
# rowan gotcha okay
# rowan yes
# rowan that makes a lot of sense
# rowan okay, i'm sending jrd now but it still isn't working D:
# puckipedia Webfinger query for roo@populator.smilodon.social unsuccessful: Invalid response mime type: application/jrd
# puckipedia somehow I don't think that was the correct response type
# puckipedia lemem see
# puckipedia I send ... appllication/json? huh, TIL.
# rowan haha
# rowan toot.cafe sends content-type: application/jrd+json; charset=utf-8
# rowan (and presumably most other mastodon)
# rowan right, so i must be doing something else wrong
# rowan and i can't for the life of me figure out what it is
# puckipedia rowan: did you try application/json?
# rowan just did, but it didn't work
# puckipedia hm
# puckipedia lemme look at Mastodon here
# puckipedia either application/
{jrd+json,json,xrd+xml,xml} or text/xml# puckipedia if you change it to one of those, I'll poke it at local Mastodon and see what else it errors
# rowan done
# puckipedia okay so the next one is really dumb. the profile in the links rel=self has to have "" instead of '' :P
# rowan a fun fact is
# rowan it used to be that way
# rowan and then i changed it to see if it helped
# puckipedia haha
# puckipedia I know that feeling
# rowan updated that too, still didn't work locally
# puckipedia still uses single quotes on populator.
# rowan uhh try it again, the heroku build might not have gone through when you tried
# rowan wait no i screwed up
# rowan i hate programming
# nightpool puckipedia: webfinger has to use jrd, which is a type of json relational data
# nightpool IIRC
# nightpool that's how it's spec'd
# rowan puckipedia: updated the thing and it should actually use the double quotes now
# erincandescent nightpool: it can content negotiate
# nightpool well i've only seen xml and jrd, and I think that's all that mastodon supports but would have to check the library to be sure
# puckipedia nightpool: goldfinger accepts the above content-types I mentioned
# nightpool ah, okay.
# puckipedia rowan: it's parsed it properly now!
# rowan iiinteresting, it's not working for me locally
# rowan might be caching
# puckipedia so Mastodon has a few more requirements on e.g preferredUsername uniqueness
# nightpool FYI rowan you can tell it's not ld+json becaues it doesn't have a @context attribute
# rowan nightpool: haha yes that would make sense if i'd thought about it :)
# rowan oh christ puckipedia what does that mean/how do you negotiate it
# puckipedia rowan: if two users on one domain with the same username and different id exist, it doesn't like it
# rowan mmmmmm
# puckipedia that should probably be fixed to try uri first, if that fails do username + domain lookup, and if *that* fails, create a new account entry
# puckipedia nightpool: ^
# rowan mhm
# rowan sweet okay that fixed the thing now i can get back to actually doing things
# puckipedia ah, the id value? :P
# rowan actually tbh i'm not sure
# nightpool puckipedia: yeah I feel that but we also require webfinger so uniqueness is not exactly an unresaonable constraint
# puckipedia nightpool: so. imagine this
# nightpool that is, we need some way to map from AP actors -> webfinger users
# nightpool enforcing a required and unique preferred username is how we do that.
# puckipedia nightpool: social group A buys domain example.com, and runs Mastodon. now, they let the domain lapse and social group B buys example.com. however, they run Kroeg, which uses different ID values
# puckipedia now, the usernames that were used with social group A can't be reused by social group B
# puckipedia and they can't federate with Mastodon instances that know of the older usernames
# nightpool hmm. as long as the webfinger returns the right URI I thiiiink it would be fine?
# puckipedia yes, but Kroeg and Mastodon don't use the same user ID
# nightpool but I'm not sure how this works in practice.
# puckipedia someone (the bridgy fed person) hit this issue in a bad way
# nightpool that was a different issue--they weren't sending a preferredUsername at all
# puckipedia nightpool: there was one
# puckipedia the issue is that the ID of the user changed, but not the preferredUsername
# nightpool "mastodon would currently interpret the actor here as me@fed.brid.gy, but it should be me@snarfed.org"
# rowan i've gotta go, but thanks for your time and patience, puckipedia!!
# puckipedia nightpool: I feel like, if the ID of a user is different but preferredUsername and domain are equal, the old account should be archived
# nightpool I understand but that's not what was happening in that ticket
# puckipedia same root cause - multiple Actor's that have the same preferredUsername
# nightpool Like I said, we expect a unique preferredUsername for all actors on a domain
# nightpool this is because we require a unique webfinger address for all accounts
# puckipedia nightpool: yes but what if the domain changes hands
# puckipedia Zakim: OH NO NOT YOU AGAIN
# nightpool ^.^
# nightpool Zakim what are you even doing here there isn't a meeting going on.
# nightpool puckipedia: if the domain changes hands then there's already an inherent conflict between posts that reference the old identifier and posts that want to reference the new identifier.
# puckipedia ... I feel like there should already be an issue about this at Mastodon. maybe even socialcg
# puckipedia https://github.com/swicg/general/issues/24 it's here now at least
# puckipedia cwebber2: yeah, same though
# puckipedia t
# puckipedia thought*
# puckipedia cwebber2: I actually mentioned the signature issue :P
# puckipedia like, what if key is leaked etc
# puckipedia anyways, sleep
# puckipedia cwebber2: what if a malicious actor updates the key
# puckipedia actually. I have an idea
# puckipedia fingerprints
# puckipedia derive a second "key loss" key from a passphrase?
# puckipedia yeah, expected
# puckipedia yes
# xmpp-social [ajordan] Lol
# xmpp-social [ajordan] puckipedia: I'm noticing a pattern with your sleeping habits ;)
# xmpp-social [ajordan] But to be fair mine are the exact same, the only difference is that I don't announce "I'm going to sleep" anymore because I know I'm lying to myself
# nightpool jaywink: the language you used was definitely normative/declarative. "a key **shouldn't** change", "the remote server should assume the identity is not the same". That's a proposal, in my head (if an implicit one--you're proposing everyone should agree with your worldview)
# nightpool The issue body text was specifically asking about AP servers, if we want to discuss more general solutions then by all means do--but this evolved out of a conversation between me and puckipedia about mastodon's AP implementation so my head was very much in that space
# puckipedia tbh this is a generic issue. but also restrictions like the one Mastodon have should probably be documented
# nightpool puckipedia: see https://github.com/w3c/activitypub/issues/271
# puckipedia nightpool: I still suggest that if a specific preferredUsername + domain combination exist, but with wrong id, the ID should be changed
# puckipedia :P
# nightpool puckipedia: it's a trade off
# nightpool I think you're correct in the general/ideal case, but so far the current behavior has caught a ton of these bugs where otherwise the behavior would be SUPER strange and confusing
# puckipedia maybe an instance administrator, somehow, should be able to reset the ID mappings for their domain
# nightpool i.e. all posts from fed.brid.gy would be associated to the *first* fed.brid.gy user
# nightpool that would be really scary!
# xmpp-social [ajordan] cwebber2: nasty Hobbitses! *gutteral* gollum, gollum