#social 2017-07-16
2017-07-16 UTC
prtksxna joined the channel
# Gargron puckipedia: can you give me the URL of the debug AP instance?
prtksxna and xmpp-social joined the channel
# puckipedia Gargron: aaaah your salmon key crashed my code hard
# puckipedia it put a salmon key in there *before* putting your user info in it?
# puckipedia ... honestly that should not be possible
# puckipedia well, it failed doing postgresql stuff, then it aborted because it's a thread that died?
# puckipedia wait this means that it's in the db still what failed
# puckipedia ... oh WHAT
# puckipedia it tried to deliver the boost of Gargron back to cwebber2?
# puckipedia hm. no wait, not a boost
# puckipedia https://mastodon.social/users/Gargron/updates/3768762 it was this
# Loqi [Eugen] @cwebber @puck is this right? https://github.com/tootsuite/mastodon/pull/4215
# puckipedia so my guess is that because it was the first time I saw this, I tried inbox deilvery to (???? somewhere)
# puckipedia ... woops, inbox delivery always delivered to all actors too
# puckipedia so I implement forwarding inbox delivery .. and forgot to exclude actors from that, instead of just forwarding to the collections
# puckipedia nuked the event queue, and restarted KRoeg
# puckipedia .. oh, and I know why the salmon key was added before the actor
# puckipedia tag uris
# puckipedia fixed that too
# Gargron someone wants me to use a full-featured json-ld parser gem
# Gargron i just want to use a simple json parser handling only the cases i expect with the AP documentation...
# puckipedia I don't do JSON-LD properly either currently, but I do have a small semi-parser-thingy
# puckipedia it's responsible for taking incoming JSON and basically translating it into a map<string, list<term>>
# puckipedia because in JSON-LD, any property can have multiple values (but for many values it makes no sense, e.g. content or id)
# puckipedia wait, I think id is excluded
# puckipedia I also have a part that 'flattens' the incoming data, and basically splits up all subobjects
# puckipedia also, I think I almost got HTTP signatures working with the activitypub publicKey property
# saranix yay!
# saranix did your server move or something?
# puckipedia lol.puckipedia.com is an instance that runs on my desktop, and that's the one running all the code I'm deving right now
# puckipedia so it 502's a lot
# saranix a lot a lot
# Gargron this is just some sorta monstrosity, i dont wanna use this https://github.com/ruby-rdf/json-ld
# Gargron if i wanted to write code like that i would've used java
# puckipedia yup that's how the json-ld api works
# puckipedia and yup that's how expanded json-ld looks
# puckipedia ActivityPub is guaranteed to be compacted JSON-LD though, which means for all but extensions it's basically just JSON
# Gargron yeah
# Gargron and we dont use any extensions right now, so it'd be fine to ignore them
# puckipedia though I would advice making a wrapper object to abstract away the fact that any key may have more than one value
# Gargron the only thing i need to change is the @context check from equality to equality and membership if its an array
# puckipedia hm, lemme check a thing...
# puckipedia yep, if a key has only one value, it's never an array
# Gargron i guess i dont see why the parser should be turing complete since day 1
# Gargron there are so many edge cases possible
# puckipedia I think I have http signature building working ...
# puckipedia testing by self-posting
# puckipedia \o/ I can create and verify http signatures!
# Gargron \o/
# cwebber2 I realized I have to do a more complicated step here; in guile's default http server system, any request handlers you set up already have http parsed into datastructures for the headers and etc, and you can't access the plaintext representation of the headers by that point. So I'll have to hack the webserver to do the normalization of the headers for http signatures *before* all that parsing occurs, which will be a bit of work. But I
# puckipedia cwebber2: pretty much, except that there's a stupid issue and that's that there's no built-in library to parse pem files
# puckipedia so I quickly hacked a thing together to parse public key PEM files, and also build them, then I store the public key as Just Another Entity in the entity store
# puckipedia most things do
# puckipedia it's just that Microsoft, tbh
# puckipedia a slight 'issue' is that the key entity is actually not in the database, so pointing the server back at itself makes it refuse to work. luckily that won't happen, as it uses an internal mechanism if the target server is the same as the origin
# puckipedia I assume you mean http signatures?
# puckipedia hehe
# Gargron hell yeah
# Gargron i mean it's pretty solidly pushed
# Gargron it's in master
# puckipedia . o O ( a http signature that also includes the signature header in the signature )
# puckipedia I only run inbox side effects if the actor receives the object
# puckipedia I mean the attributedTo/owner of the object
# puckipedia e.g.
{type: Like, object: {type: Note, content: hello, attributedTo: puckipedia}, to: cwebber2}
won't run side effects even if you are on the same server# puckipedia but once you e.g. cc me and ensure that it gets to me, it runs it
# Gargron i would run side effects only if the object is new to the db
# Gargron but again - i have a relational db
# puckipedia it kinda depends. I am kind of simulating an environment where each user runs their own server
# Gargron yes we store likes relationally too
# Gargron you can't double-like something
# Gargron that being said thanks for reminding me my WIP parser did not consider liking/unliking and follow/unfollowing yet
# Gargron hm i would have to do some weird shit to make syntax like that work
# Gargron but yeah no i just realized we dont have serializers for follow/unfollow/favourite/unfavourite yet
# Gargron i also need block/unblock, i dont even know if that's in AS vocabulary but it should be
# Gargron would it be Unfo: Favourite also?
# Gargron and Undo: Follow?
# puckipedia yep. Undo: Like though
# puckipedia and it's Create vs Delete, for reasons
# Gargron Undo: Florp
# puckipedia yeah. but we're stuck with it now
# Gargron wait what? which ones are Undo and which ones are Delete?
# puckipedia Gargron: Create vs Delete, Like vs Undo:Like, Follow vs Undo:Follow, etc
# cwebber2
{"id": "https://forp.example/act/undo123", "type": "Undo", "object": {"id": https://forp.example/act/undo123#object", "type": "Block", "object": "https://foo.example/annoying-user/"}}
# puckipedia would that be c2s or s2s?
# puckipedia I think for c2s it's acceptable ... but for s2s? mh, maybe
# cwebber2 "object": {"id": https://forp.example/act/undo123#object",
jaggered345 joined the channel
# puckipedia definitely when it isn't yet in the spec to look it up :P
# puckipedia I think Mastodon keeps track of block IDs
# Gargron i wouldn't care about the id of a block/unblock or follow/unfollow or like/unlike object because those are binary operations
# puckipedia when in the inbox, right?
# Gargron like, if i know "x unblocks y", that's all i need to know, i don't need an "unblock" object
# puckipedia just as in, mastodon being at the receiving end of a s2s unblock message
# Gargron yeah
# puckipedia though, in the case of Mastodon, it keeps track of blocks .. until you remove them
# Gargron it could be an IntransientActivity or whatever
# Gargron or Transient
# Gargron i don't remember which is which
# Gargron puckipedia: yes, but it's "does a block between x and y exist", not "does block with id exist"
# puckipedia I mean, technically a follow/undo of that follow should be resolvable at any time for any user, and have a unique id
# puckipedia I say *technically* because my server never really removes stuff from the cache, just makes it 'please try to get this again' and uses the existing item as a fallback for if it isn't available anymore
# puckipedia hm, In the case of http signatures that is needed. but
# puckipedia JWT has the sub claim
# puckipedia oh taht way ...
# puckipedia anyways, I think you should not forward credentials for viewing objects
# puckipedia if you can't verify whether a user can view an object, I suggest either just keeping it as an id, or maybe just refusing to accept the object?
# puckipedia wait, I built that into Kroeg a while back when I added server-server federation lol
albino joined the channel
# cwebber2 explicit vs implicit https://github.com/w3c/activitypub/issues/242#issuecomment-315631338
# puckipedia I think it's mostly followers?
# saranix just consolidation if there is more than one to on the same server
# cwebber2 Gargron: this one specifically https://github.com/w3c/activitypub/issues/242#issuecomment-315631633
# puckipedia I still feel like an explicit list is nicer...
# puckipedia ... actually, do we have any mechanism for follow /requests/?
# saranix nothing to notify a denial...except a Block response perhap. A bit blunt, but...
# puckipedia so a way I would do this is by e.g. manually editing the followers list
# saranix "should" side-affect update the collection... but that collection is allowed to be filtered or not given at all
# puckipedia exactly
# saranix audience and cc distinguish, no?
# puckipedia I would consider "your actor ID is in to/cc" as being directly targeted
# puckipedia and else it's passive
# xmpp-social [ajordan] cwebber2: but you're talking about distinguishing two cases using the endpoint it's delivered to
# puckipedia mmh. assumes that both servers have a knowledge of 'follower'
# xmpp-social [ajordan] cwebber2: IIUC saranix's q they thought that
# saranix don't forget Tag, both Type Person and Type Mention under Announce depending on which spec you follow :-p
# xmpp-social [ajordan] > <cwebber2> > If you use explicit delivery, there is no way to distinguish between a truly targeted post (notification-worthy) and a passive post to followers (home). So followers URI must be handled imo.
# puckipedia so I imagined a small situation. Imagine a bunch of microservers all hosting one ActivityPub user. and they have a shared sharedInbox, and that sharedInbox is hosted by a trusted 3rd party that filters on spam, and then forwards it to each user
# xmpp-social [ajordan] Meant you were suggesting using delivery to a shared inbox as a signal for *why* something was delivered
# xmpp-social [ajordan] Ahhh okay
# puckipedia cwebber2: tbh inbox delivery should not matter no matter what endpoint you use
# puckipedia the issue with follower collections is assuming that noone on that server is blocked
# puckipedia well, I mean, posting to all followers on a server
# xmpp-social [ajordan] ^^^
# puckipedia unless we federate block activities
# saranix wait so you guys aren't talking about this then: https://www.w3.org/TR/activitypub/#public-inbox-delivery
# cwebber2 see the forementioned issue: https://github.com/w3c/activitypub/issues/242
# puckipedia saranix: so basically an issue is that having e.g. 10000 followers means that you have to do inbox delivery 10000 times. So why not have e.g. an endpoint where you post a list of inboxes it should be delivered to, and the object
# saranix I'm all for a siteInbox. That makes sense to me.
# puckipedia so as I described it?
# saranix well, it's semantic, but something that indicates that the server receiving it is expected to do all possible deliveries, and not just to the inbox "owner"
# saranix *local* deliveries
# puckipedia tbh, I would prefer that that list of deliveries (local, yes) would be explicitly sent by the originating server
# puckipedia I might look at how much work it'd be to make a sharedInbox as I described it
# saranix puckipedia: now your spam filtering idea makes sense. I like it!
timbl joined the channel
# xmpp-social [ajordan] I second what cwebber2 just said
# puckipedia ah, so Twitter/Mastodon style
# puckipedia I think the former
# puckipedia hm. Depends on how you want AP to be used
# puckipedia imagine a facebook style privacy setting
# puckipedia cwebber2: so. Twitter. In Twitter, blocks aren't really 'federated'
# puckipedia until you actually go to that user's profile
# puckipedia imagine linking a blocklist. Should everyone on that blocklist get a notification that you blocked them?
# puckipedia I think part of the reason blocklists work is because you can't determine who used a blocklist.
# puckipedia jaywink: good point, an AP block feels more like an ignore
# xmpp-social [ajordan] I wonder if there's something to be said for an endpoint that let you say "deliver to followers minus these people" and leave the reason unspecified
# xmpp-social [ajordan] You could *guess* it was because of a block but wouldn't be sure
# xmpp-social [ajordan] It could be an optimization
# puckipedia ajordan: I feel like that'd be bad. why not just send the list of people it *should* be sent to
# puckipedia and I really don't like the idea of federating a Block into a weird vague server-inbox
# xmpp-social [ajordan] puckipedia: because we've got pushback from Mastodon on that (to be clear that's the approach I'd prefer too)
# xmpp-social [ajordan] cwebber2: yes but with a lower degree of confidence
# puckipedia cwebber2: but servers could still decide that if you Block someone, you remove them from your follower list
# xmpp-social [ajordan] I think you're right though, it's still too explicit
# Gargron i was actually gonna ask about how to implement follow requests
# Gargron in ostatus i was using request-friend->person, authorize->request-friend->person vs reject->request-friend->person
# xmpp-social [ajordan] If we had some mechanism to ACK/NACK followers we could just say that blocking removes people from Followers (and federate that info)
# saranix after digesting it a little I'm down with sharedInbox. much more flexible. allows for cool extra features, and semanticly could be siteInbox if that's what it is
# puckipedia cwebber2: so Accept vs Reject follower
# puckipedia a Follow*
# xmpp-social [ajordan] Then it's possible the person just changed their mind about you following them and didn't do a block
# xmpp-social [ajordan] Less leaks
# puckipedia should we notify on a reject?
# saranix ask the user
# xmpp-social [ajordan] cwebber2: ah yeah
# xmpp-social [ajordan] I don't know the vocabulary as well as I could
# Gargron mastodon has a block and a mute, and the mute is what you'd call "ignore" in diaspora, and the "block" is supposed to remove the person from your followers list and prevent them from seeing your content as much as possible (everybody understands it's best-effort since ppl can log out)
# saranix well more like "stop sending me crap I'm not following you"
# Gargron i think federating a block is ok. you are trusting the server, not the user you're blocking, unless it's a rare case where blocked user = admin
# puckipedia ^
# Gargron chris, i mean heck, i was advocating for a block to behave like an ignore early on. i got overturned on that. this is what we have now
# xmpp-social [ajordan] ^^^
# Gargron yes
# Gargron normal people want to be able to stop someone from seeing their public posts, even if it means little
# puckipedia how about servers that would ignore blocks and just keep on delivering
# Gargron the worst thing if blocks are not implemented is that the block starts behaving like an ignore.
# Gargron filtering incoming content is a non-problem
# puckipedia correct. but they could then still view that post
# Gargron i agree with 2nd but
# Gargron i dont think you can have an endpoint that decides on delivery target like that without examining to/cc
# puckipedia so the authorization part (who can see specific entities or not) in ActivityPub servers is not defined in the spec?
# Gargron because what if i target at all my followers, but also cc public
# saranix sharedInbox - use the envelope to determine delivery
# Gargron ^
# xmpp-social [ajordan] How can clients other than the server's web UI tell if the server federates blocks? They need to now that in order yo present the option properly
# saranix yes
# Gargron if you get a followers URI, you can resolve that to get a Collection, and theoretically sync up supposed followers that way
# saranix well no
# puckipedia Gargron: yes but imagine 10000 followers
# Gargron though again thats kinda weird in terms of scalability
# Gargron well thats my point exactly tho
# Gargron imagine 10000 followers in a "to"
# saranix actually, I was thinking, if you have a link to the collection, the server fetches the collection and only sees which people on it's own server
# puckipedia saranix: D: that can't work
# Gargron you could use a
# Gargron uh
# Gargron i forget the name of the algorithm
# Gargron not bit mask
# saranix oh yeah
# saranix it really should though
# puckipedia bloom filter?
# Gargron yes
# puckipedia I think that shouldn't be in the spec
# Gargron yeah idk
# saranix why isn't there a server key?
# puckipedia saranix: ActivityPub has no concept of a server
# saranix and server inbox...
# saranix yeah but all the existing protocols Zot,diaspora, etc... do
# Gargron okay
# Gargron yes
# Gargron i believe technically you could do other collections as well as long as you track their semantic meaning somehow
# Gargron for example i intend to save the "followers" value from the actor, to keep it as the followers URI, so i know what it means when it appears
# Gargron same could be done for other collections that are linked from somewhere
# saranix I'm coding shareInbox in right now... for individuals only
# xmpp-social [ajordan] Hahahaha I remember that ad
# xmpp-social [ajordan] Loqi: not really
# xmpp-social [ajordan] q+
# Gargron yes
# xmpp-social [ajordan] > How can clients other than the server's web UI tell if the server federates blocks? They need to now that in order yo present the option properly
# puckipedia ... mh. yes to latter, ehhhh to former
# xmpp-social [ajordan] wow that is *riddled* with typos
# xmpp-social [ajordan] s/to now/to know/
# xmpp-social [ajordan] s/yo/to/
# xmpp-social [ajordan] cwebber2: you misunderstand
# puckipedia mmh. mmmgggghhhh
# saranix +1
# xmpp-social [ajordan] say I connect a desktop client to *my* AP server
# xmpp-social [ajordan] I want to block problematic@example.com
# xmpp-social [ajordan] how does my desktop client know whether to present it as a "block" or "ignore"? because which one of those the behavior matches will depend on whether my server federates blocks
# puckipedia "ignore user" vs "block user"
# xmpp-social [ajordan] yes
# xmpp-social [ajordan] the distinction is important
# xmpp-social [ajordan] ughh yeah. right
# xmpp-social [ajordan] I mean the one big distinction I see is that if blocks are *not* federated than potentially you're also delivering notes and stuff to a "blocked" user who's in your followers
# puckipedia jaywink: yes, but that's the other way
# xmpp-social [ajordan] cwebber2: how so
# saranix if person A blocked person B, and person B sends person C a like for person A's post, but Person C likes person B and does NOT block, then why shouldn't person C be able to see the like? ergo, it's still advisory
# puckipedia mmmmmghhhhh I really really want to be explicit about who to deliver to...
# puckipedia I feel like maybe we should make it a SHOULD deliver to those and only those
# xmpp-social [ajordan] cwebber2: right, I was just about to bring that up
# xmpp-social [ajordan] q+
# puckipedia jaywink: yes, but I mean basically deduplicating requests by sending a list of inboxes to deliver to, and the object to put into all those inboxes
# xmpp-social [ajordan] cwebber2: I suggested that 20 minutes ago hahaha
# saranix list of ids, not inboxes
# xmpp-social [ajordan] lol ya and I think I decided against it for some reason
# puckipedia saranix: mh, I mean in the style of e.g. "please send this object to user A, B, C specifically"
# saranix I'm implementing sharedInbox as we type. solves many problems.
# puckipedia cwebber2: and I feel like following should be a non-special case :P
# xmpp-social [ajordan] does anyone want to hop onto a Mumble call?
# puckipedia one sec
# saranix no mic
# saranix jaywink: "here is a post involving ids that list you as a caretaker, please deliver to them however you do"
# saranix you won't deduplicate private posts?
# saranix kind of a waste...
# saranix you are, not the rest of us
# saranix exactly!
# saranix no cwebber2!
# saranix that would be bad
# puckipedia tries to mumble but got a shitton of stuff open
# saranix wastes 90% of use case it would be used for
# saranix in my world, most posts are private, nearly all
# saranix deduplication is needed for them just the same. Makes no sense to exclude them
# saranix In my usecase "followers" is irrelevant... it's "who has permission to see it"
# saranix yeah I guess
# saranix but it wouldn't be address: "to: saranix's followers'.. it would be address 'to: a, b, c' (who are saranix's followers)
# saranix if a,b,c are on the same server with the same 'sharedInbox', then I can do one delivery
# saranix I'm saying most users don't share their follower list
# saranix and it is default
# saranix MY server of course knows MY list, but if some people from my list on popular.example are shared, they don't know they are on a list together, nor what I named that list, the server can only correlate that they are all on a bto: list together (which it should politely ignore and not keep track of)
# saranix NO!
# saranix waste of bandwidth for no added benefit
# saranix as you said, the server can correlate anyway
# saranix you aren't saving any security
# saranix popular.example DOES NOT see someother.example's bto's, only the ones that share that particular sharedInbox
# saranix so in puckipedia's usecase, popular.example and someother.example might all have 3rdparty.example/sharedInbox listed as their sharedInbox, and I can deliver to them all bto there, semantically representing to the server that each one should not receive a list of the other recipients, but other than that it is an exact copy for each
# xmpp-social [ajordan] saranix: are you "unnamed"?
# xmpp-social [ajordan] thx
# xmpp-social [ajordan] whoever just joined the Etherpad, please name yourself
# xmpp-social [ajordan] top-right
# Gargron there's a couple more things that don't yet map onto AP
# Gargron i can stick the "status language" into a contentMap with a single key=>value
# Gargron but what about the "conversation" as it is used with ostatus:conversation
# Gargron e.g. URI passed back and forth so that even if you lose the tree structure of replies you can still categorize them together
# Gargron aaand the "locked" state of a profile, e.g. indicator that following will require a follow request
# puckipedia Gargron: we're working on the locked state at this moment
# puckipedia and I translate the OStatus conversation as _:conversation but that's a semi-extension that I only do for Atom
# puckipedia also we're mumbling again
# Gargron _:conversation?
# xmpp-social [ajordan] cwebber2: q+
# saranix Hmm... looks like the spec already says MUST do site-wide delivery even from user's inbox: https://www.w3.org/TR/activitypub/#inbox-delivery
# puckipedia saranix: with a many asterisks
# puckipedia only to collections that the remote server cannot deliver to
# saranix yeah, what does that even mean?
# saranix and how would it know?
# puckipedia collections owned by the receiving server
# saranix exactly
# saranix no one is saying relaying, I said site-wide
# saranix or are you saying collections like Type: Group that don't have an inbox? seems a shame to just restrict it to them...
# saranix especially since no one will ever use that :-P
# saranix They'll just create an Actor WITH an inbox for it?
# saranix scratches head
# xmpp-social [ajordan] q+
# puckipedia
{type: Actor, pinned: https://example.com/note/example-note}
# xmpp-social [ajordan] cwebber2: I'm summarizing it in w3c/activitypub#242
# puckipedia
{type: Travel, actor: puckipedia, origin: computer, target: bed}
JanKusanagi joined the channel
# xmpp-social [ajordan] puckipedia: see ya!
# puckipedia I put a few notes in here about the pinned post: https://github.com/swicg/general/issues/12#issuecomment-315644330
# puckipedia well there's the entire note
# puckipedia okay really moving to bed now
# saranix That's great, but could we not say "like on Twitter", and just say "like on ever other discussion software that came before"? :-P
# saranix As for pinning it to a profile, that conflates profile and home stream. Also, what if you want a different pinned post for each stream collection?
# saranix Should be an attribute of the post itself...
# saranix or of the collection: items:[], pinnedItems: []
# xmpp-social [ajordan] saranix: can you write up a comment that I can copy and paste onto GitHub? this will get lost on just IRC
# xmpp-social [ajordan] cwebber2: sure :)
# xmpp-social [ajordan] mostly doing it for myself to think things through and so *I* don't forget :P
# Gargron cwebber2++
# saranix ate my formatting unfortunately
# Loqi [strugee] Link to the Etherpad from the Mumble call: https://public.etherpad-mozilla.org/p/activitypub-implicit-explit
Someone correct me if I'm wrong but I believe this was the consensus:
1. sharedInbox is used only for public and followers delivery, ev...
# saranix I must vigourously object to not specifying that a server should deliver to all the recipients it hosts when receiving a message to the sharedInbox. It need not look up any objects like puckipedia says in (https://github.com/w3c/activitypub/issues/242#issuecomment-314882488). It needs only to deliver to it's own users it does not need to fetch anything remote for that.
# saranix err I read that wrong, so that actually agrees with me
# saranix That a receiving server should deliver to all recipients, and that a sender should explode the collection to a list
# Loqi [strugee] (From saranix on IRC, who does not have a GitHub account:)
I suggest we add a property to the AS2 Collection type (https://www.w3.org/TR/activitystreams-vocabulary/#dfn-collection): e.g.
```json
{
"@context": "https://www.w3.org/ns/activity...
# saranix thx
# saranix ajordan++
# saranix fair point
# saranix I'm trying to think how it would be used in a federated context anyway... like if your collection has pinned things I'm probably not going to want that in my stream-of-all-streams, on my local client... but if I view it at the stream source (e.g. your website), your websever is rendering the pinned posts to html anyway
# xmpp-social [ajordan] saranix: Mastodon's UI lets you view users within your home site
# xmpp-social [ajordan] *remote users
# saranix interesting... yeah I'm starting to figure out a UI from it... could be lots of fun
# saranix just had one of those ideas that expands the scope of the project by several orders of magnitude