#social 2018-08-03
2018-08-03 UTC
# 
puckipedia <tuxether[m]> How does Kroeg handle this? ^ <- complete generic everything
# puckipedia I parse it into expanded JSON-LD and use something not-quite-RDF
# donpdonp up201705417: i think i just posted something to diogo's inbox
# puckipedia also I built a guestbook on ActivityPub https://puckipedia.com/guestbook
# up201705417 donpdonp: a follow request?
# donpdonp yes
# up201705417 if so, it is here: https://www.hackthis.space/social/index.php/diogo/
# up201705417 you show up as a follower
# donpdonp rad.
# donpdonp oh that was from before
# up201705417 oh, well, you can undo your follow and follow again to test xd
# dansup puckipedia: nice guestbook
# donpdonp i dont get how its an activitypub guestbook
# puckipedia donpdonp: @guestbook@puckipedia.com
# puckipedia also https://puckipedia.com/guestbook.json
# donpdonp o.O
# donpdonp POST https://puckipedia.com/guestbook/inbox => 500 err
# donpdonp yea, i broke something.
# puckipedia ┗ POST https://puckipedia.com/guestbook/inbox
# puckipedia [
{"@id":"uuid","@type":["https://www.w3.org/ns/activitystreams#Follow"],"https://www.w3.org/ns/activitystreams#actor":[{"@id":"https://donpark.org/"}],"https://www.w3.org/ns/activitystreams#object":[{"@id":"https://puckipedia.com/guestbook"}]}]# puckipedia L err tried to POST to a non-inbox/outbox entity
# puckipedia hm
# puckipedia yeah. it broke
# donpdonp up201705417: when i follow you from donp@donpark.org (note different from donpdonp) I get "Already following" so thats good. but I dont see me on the list https://www.hackthis.space/social/index.php/diogo/subscribers
# puckipedia donpdonp: try again
# puckipedia right.
# puckipedia woops, I know why it's saying that
# puckipedia donpdonp: it's because your auth is broken
# puckipedia it figured out "uuid" isn't in the same namespace as "anonymous" so it breaks a bunch
# donpdonp wha?
# puckipedia you sent "id": "uuid"
# puckipedia and http signature isn't valid
# donpdonp well thats just sloppy.
# donpdonp the signature should be valid though.
# puckipedia what's the header you send
# puckipedia there's like, a few semi-bugs here
# donpdonp hmm i dont log enough stuff on my side to answer that
# donpdonp does your http signature impl pay attention to the list of headers?
# donpdonp its only 3 headers that are signed
# donpdonp unlike mastodon which lists like 7 of them.
# puckipedia it does
# donpdonp ok.
# donpdonp well im out of brain-power for today. i'll come back to this tomorrow
# puckipedia however, it does not validate a Digest header if sent
# puckipedia (it will still use it as header if passed in, duh)
# donpdonp thats ok cuz i dont send one
# up201705417 donpdonp: it is correct
# up201705417 they have the same id
# donpdonp up201705417: ah i see. thx.
# up201705417 I think I got the Accept Headers working now
# up201705417 and Follow is working between GS instances locally
# up201705417 will now try again with mastodon
# up201705417 Mastodon still says "404 Record not found."
# up201705417 ._.
# up201705417 also, when I click on Follow in Mastodon it doesn't send any request to my node
# dansup I wonder if that is because mastodon still thinks its OStatus
# dansup up201705417 ^
# up201705417 hackthis.space has OStatus fully disabled
# up201705417 and everything else is working
# dansup it could be webfinger
# up201705417 webfinger is an hardcoded file on hackthis.space
# up201705417 https://www.hackthis.space/.well-known/webfinger
# up201705417 the only entry it has is for activitypub
# dansup try removing acct: from subject
# up201705417 okay
# up201705417 done, trying again
# up201705417 nothing change
# up201705417 s/change/changed
cdchapman joined the channel
# dansup hmm, have you tried pleroma or are you still only testing against mastodon?
# up201705417 just tested with pleroma
# up201705417 the best of pleroma is that it is all "ok"
# up201705417 ActivityPub Postman: Delivery result with status code 200: "ok"
# up201705417 yet: https://pleroma.site/users/pixeldev
# up201705417 I don't think I am in the followers list
# up201705417 can you check?
# up201705417 ah, wait, the problem isn't in following a mastodon user, that works just fine, the problem is in being followed by one
# up201705417 I haven't created a dummy pleroma user to test it out
# up201705417 (and yes, I've just been testing with mastodon so far)
# dansup ah ok
xmpp-social, vasilakisfil, saranix, cdchapman and stephank joined the channel
# stephank Hi! I'm building a simple single-actor server as an experiment. My current implementation always prefers `sharedInbox`. Is there any reason to prefer a personal inbox, when `sharedInbox` is available?
# tuxether[m] stephank: writing to a personal inbox can set the 'isAttributedTo' field automatically.
# saranix stephank: not that I kbow of. AFAIK it is legal to point personal inboxes at the same url as the sharedinbox
# stephank Alright, thanks for the quick answers! I'll keep it as is for now. @tuxether[m]: But that should be set to the sender? Not sure how the receiver would set that differently, between personal or shared inboxes. (I only have Mastodon source handy, it doesn't seem to have much logic specific to that field.)
# tuxether[m] stephank: whoops. sorry, I misread.
# stephank 👍
# donpdonp can someone explain sharedInbox to me?
# tuxether[m] there should be no difference.
# donpdonp ive been pleasantly ignoring it to date.
# donpdonp *mind blown*
# donpdonp so id post to mastodon.xyz/sharedInbox instead of copies to mastodon.xyz/bob/inbox mastodon.xyz/jill/inbox mastodon.xyz/betty/inbox
# donpdonp assuming those profiles listed the same sharedInbox.
# donpdonp nod.
# donpdonp thats a curious concept.
# donpdonp im filling up https://botsin.space/@zrobo with test msgs. woo.
# up201705417 stephank: when a message is sent to a personal inbox on GNU Social the owner of that inbox automatically enters in CC even if not specified
# up201705417 I wonder if this is wrong: https://www.w3.org/TR/activitypub/#object-without-create
# up201705417 on example 15 no actor is specified
# up201705417 but on example 16 it shows up
# stephank up201705417: Ah, that's interesting! Sounds a bit like a short-hand for sending private messages, where the object doesn't have any to/cc/bcc?
# up201705417 to and cc it has, but doesn't have a Create wrapper
# stephank Ah sorry, I was only replying to your first message.
# up201705417 ah, yes, it's a short hand
# stephank up201705417: Those examples look fine, I think? In client-to-server, the client doesn't have to specify who created the object, because it's usually implied by authentication. The server adds `attributedTo` there, and also wraps it in an activity with the `actor` field.
# up201705417 (hm, not necessarily private messages, I don't have those implemented yet, UI changes will be needed to add those on GNU Social, for now it's all public)
# up201705417 stephank: my bad, was thinking of S2S
# stephank Haha, I've mixed those up a couple of times. May just as well have been separate specs. :)
# stephank up201705417: Public is not implied by the spec, though? I'm not sure if that makes that behaviour slightly dangerous, e.g.: address someone on GNU Social in private, but it's suddenly public.
# up201705417 yes, that's right, but currently GNU Social doesn't allow remote private messages (thus the convention adopted by the plugin)
# up201705417 but that touches an interesting point
# up201705417 what would be the proper way of notifying the remote instance that a given request is not allowed?
# up201705417 fake success and don't do anything?
# up201705417 or should I send a Reject back?
# donpdonp whoho. a post in botsin.space ends up in the local sqlite3
# puckipedia <up201705417> what would be the proper way of notifying the remote instance that a given request is not allowed? <- ignore or reject
# puckipedia oh ehm
# puckipedia not follows
# puckipedia just ignore
# puckipedia I thought you mean "given follow not allowed"
# puckipedia <aaronpk> and if you're making a single-user server, then you have no need to have a sharedInbox since there's no difference <- not quite? sharedInbox can get arbitrary as:Public posts too
# puckipedia (mastodon bug sends arbitrary posts into my inbox though :<)
# up201705417 puckipedia: gnu social doesn't allow to undo a repost/boost for example, at the moment I'm faking success, but maybe there is a better way of handling it?
# puckipedia add support to undo a boost :P
# up201705417 xd
# puckipedia but like, you should probabkly just accept the message
# stephank (I'd agree, currently just return 202 for everything that looks well formatted and passes the signature check.)
# up201705417 I think it would be nice to let the remote node know that what he tried to do just isn't acceptable
# puckipedia except
# puckipedia remote nodes will just say "oh, i failed to send the message, let's retry in 5 minutes"
# up201705417 yeah, mastodon loves to spam me with stuff I already received
# up201705417 the plugin was returning an error message for repeated notices
# puckipedia ignore repeated activities with the same name btw
# up201705417 and mastodon assumed something failed an retried to send
# stephank I think Mastodon only retries for >=500? It'd make sense according to HTTP to not retry, e.g., 4xx status codes.
# up201705417 500 is the default error code the plugin uses
# up201705417 I will review the current return handler and see how to improve it
# puckipedia stephank: I hope that's not the case, else there's gonna be a bad time
# puckipedia (what if your public key changes within a day?)
# up201705417 (I think someone said that mastodon is able to detect that and update it)
# puckipedia only after a day
# stephank How so? The best way to tell another server it's doing something wrong is a 4xx status code. The remote is essentially a client, and if it tries something funny, it gets a client error.
# up201705417 (don't know how it works underneath the hood though)
# puckipedia up201705417: it tries to update the profile after about a day since last profile update
# up201705417 I see, all right, will proceed to the corrections of the day! xD
# stephank Do implementations currently rotate keys? If a server rotates keys, it should still accept signatures from an older key for the duration of caches, at least.
# puckipedia stephank: not yet, no. I don't t hink accepting older key signatures is a good idea imo?
# stephank Well, for compromised keys you shouldn't, but I think you should for regular key rotation
# puckipedia what's the difference even
# stephank I guess I'm no expert either, but there's precedent in JWT / JWK, and also how Node.js apps often do cookie signing using keygrip: https://www.npmjs.com/package/keygrip
# puckipedia ... does the w3id stuff have scopes?
# puckipedia ehm, https://web-payments.org/contexts/security-v1.jsonld
# puckipedia mm. no.
# stephank But my worry is that key rotation can happen automatically at a set interval, like every couple of months, while you may be serving that key with cache max-age of a week. You have to bridge that week gap somehow.
# puckipedia serve two keys :P
# puckipedia sign with both keys :P
# stephank Ah, I guess I'm thinking the wrong way around. But yes, it'd mean having to sign twice for that duration. Hmm, my server currently doesn't deal with multiple signatures.
# puckipedia mine does :D
# puckipedia probably gonna add it into Mastodon too?
# stephank Don't know about that, but castling.club now should handle multiple signatures too. :p
# donpdonp my project doesnt even verify signatures <evil laugh here>
# donpdonp i'll get around to it :)
githree joined the channel