#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
#
ajordan puckipedia: at least it failed loudly and obviously :D
#
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
#
ajordan hahaha
#
puckipedia ... oh WHAT
#
Loqi nice
#
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!
#
Loqi does a happy dance!
#
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
#
puckipedia https://lol.puckipedia.com/auth/key?id=https%3A%2F%2Flol.puckipedia.com%2Fusers%2Fpuckipedia
#
Gargron this is just some sorta monstrosity, i dont wanna use this https://github.com/ruby-rdf/json-ld
#
Loqi [ruby-rdf] json-ld: Ruby JSON-LD reader/writer for RDF.rb
#
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 hey puckipedia !
#
cwebber2 congrats!
#
cwebber2 Gargron: so, imo
#
cwebber2 Gargron: about json-ld
#
cwebber2 you can get away with just a json parser, but the ideal usage of json-ld for applications like ours involves *usually* just using a json parser anyway
#
cwebber2 Gargron: if you go into extensionville and etc, the ideal way to do it would be:
#
cwebber2 - when you get a foreign object, expand it (to its unambiguous state), then compact it down to your local context
#
cwebber2 - then store that
#
cwebber2 - now you can use all your tools and be free of any ambiguities
#
cwebber2 that said, we did design AP and AS2 so that, assuming you don't use any extensions, you can not use any json-ld tooling at all
#
cwebber2 oh I see puckipedia said all the things I said :)
#
cwebber2 puckipedia: btw did you find http signatures easy enough to implement?
#
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
#
cwebber2 should be able to do it, and that's more an artifact of the assumptions of this system than anything.
#
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
#
cwebber2 puckipedia: huh, yeah I know the library I'm using (libgcrypt) has support for parsing PEM... I guess I haven't thought about how common that is
#
cwebber2 it's cool you got it hacked together so fast!
#
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
#
cwebber2 hey Gargron, puckipedia, I heard back from Mastodon
#
puckipedia I assume you mean http signatures?
#
cwebber2 derp
#
cwebber2 yep
#
cwebber2 I meant to say back from Manu
#
cwebber2 but he mentioned Mastodon in the email
#
cwebber2 me> "is there intent to keep pushing this spec"?
#
cwebber2 manu> Yes.
#
cwebber2 manu> We're waiting for deployments like Mastodon before taking it to the HTTP WG. The thing that's keeping it from progressing is my lack of time to push it forward at IETF. I already have clearance from the IETF HTTP WG to push it forward there.
#
puckipedia hehe
#
cwebber2 Gargron: so yeah, pushing it forward in Mastodon will help :)
#
cwebber2 \o/
#
Gargron hell yeah
#
Gargron i mean it's pretty solidly pushed
#
Gargron it's in master
#
cwebber2 :)
#
puckipedia . o O ( a http signature that also includes the signature header in the signature )
#
cwebber2 puckipedia: that... wouldn't be possible right?
#
cwebber2 you'd need some incredible fixed point math magic that's IIUC not computationally possible in a cryptographically sound system
#
cwebber2 puckipedia: btw, what was your stated technique to avoid double-processing of inbox side effects again?
#
puckipedia I only run inbox side effects if the actor receives the object
#
cwebber2 wait, the actor?
#
cwebber2 but the actor's the one sending it right?
#
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
#
cwebber2 right, gotcha.
#
puckipedia but once you e.g. cc me and ensure that it gets to me, it runs it
#
cwebber2 makes sense.
#
cwebber2 thanks puckipedia
#
Gargron i would run side effects only if the object is new to the db
#
Gargron but again - i have a relational db
#
cwebber2 Gargron: that was what I was thinking, but
#
cwebber2 well
#
cwebber2 actually wait, that still might be the right approach
#
cwebber2 I was going to say you wouldn't increment likes of it etc
#
cwebber2 but you might actually be mirroring your track of likes you've seen,e tc
#
cwebber2 and I'm pretty sure Mastodon does track that
#
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
#
cwebber2 Gargron: btw a piece of advice on the parser that I think both puckipedia and I encountered
#
cwebber2 you may want two helper utilities for retrieving values from an object
#
cwebber2 something like object.get('to').as_array() and something like object.get('content').single()
#
cwebber2 because {"to": "http://example.org"} and {"to": ["http://example.org"]} are both valid ways to encode single objects
#
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
#
cwebber2 we have Block and {Undo: {Block}}
#
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
#
cwebber2 still not a fan of removal of the many Unfoo verbas
#
cwebber2 *verbs
#
puckipedia yeah. but we're stuck with it now
#
cwebber2 I objected to it iirc but everyone else wanted to cut the vocab down
#
Gargron wait what? which ones are Undo and which ones are Delete?
#
cwebber2 Gargron: https://www.w3.org/TR/activitystreams-vocabulary/#inverse
#
puckipedia Gargron: Create vs Delete, Like vs Undo:Like, Follow vs Undo:Follow, etc
#
cwebber2 Gargron: it's inconsistent, we have some Unfoo verbs but not others.
#
cwebber2 Gargron: btw, a problem you'll encounter (and the reason why I don't like the removal of Undo)
#
cwebber2 is I don't want to look up the original Block just to undo it
#
cwebber2 so, what I consider valid:
#
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/"}}
#
cwebber2 wait, let me pretty-print that
#
puckipedia would that be c2s or s2s?
#
puckipedia I think for c2s it's acceptable ... but for s2s? mh, maybe
#
cwebber2 {"id": "https://forp.example/act/undo123",
#
cwebber2 "object": {"id": https://forp.example/act/undo123#object",
#
cwebber2 "type": "Undo",
jaggered345 joined the channel
#
cwebber2 "type": "Block",
#
cwebber2 "object": "https://foo.example/annoying-user/"}}
#
cwebber2 puckipedia: I'd think either, but it seems "more" acceptable for c2s than s2s, I agree
#
cwebber2 Gargron: I wonder how you feel about this
#
cwebber2 IMO it's too much to ask clients at least (maybe servers shouldn't have difficulty) to look up the original activity just to undo it.
#
puckipedia definitely when it isn't yet in the spec to look it up :P
#
puckipedia I think Mastodon keeps track of block IDs
#
cwebber2 puckipedia: yeah
#
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
#
cwebber2 puckipedia: was that a "when in rome" joke?
#
cwebber2 oh
#
cwebber2 no it wasn't
#
puckipedia just as in, mastodon being at the receiving end of a s2s unblock message
#
cwebber2 Gargron: so I assume you agree that fragment ids are totally fine here
#
Gargron yeah
#
cwebber2 cool
#
cwebber2 thumbs up :)
#
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
#
cwebber2 hey Gargron
#
cwebber2 I thought of a justification for having a separate key per user
#
cwebber2 Gargron: imagine you were actually using http signatures to allow servers to retrieve content on behalf of a user
#
cwebber2 which I think is a good idea btw
#
cwebber2 Gargron: in the call, we talked about user A posting a post to user B, then C getting wind of it, how can C verify that content is real?
#
cwebber2 and we said, sans linked data signatures, C's server should look things up using C's credentials
#
cwebber2 well assuming each user has a separate key, this "isolates" checking whether that user has credentials to view that object
#
puckipedia hm, In the case of http signatures that is needed. but
#
puckipedia JWT has the sub claim
#
cwebber2 puckipedia: maybe the audience claim is even more specific to that? but anyway, I'm not sure, would that really carry over to the forwarded reference to the object?
#
cwebber2 assuming a reference to the object is passed along, telephone style
#
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?
#
cwebber2 I'm not suggesting forwarding credentials
#
cwebber2 I'm talking about B referencing A's post
#
cwebber2 in say, a Like or something
#
cwebber2 or a Share
#
cwebber2 and C wanting to make sure that A's object is really what B says it is
#
cwebber2 so C should have their own credentials to look it up, to make sure that C can really access it anyway
#
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
#
Loqi [cwebber] > I am strongly in favour of a sharedInbox endpoint that would respect audience targeting (such as "followers collection"). Listing individual recipients does not scale well. My decision is also largely informed by business logic implemented in Masto...
#
cwebber2 Gargron: I wonder what you think of this
#
cwebber2 is the last comment on that issue
#
cwebber2 is "followers" the main thing you need implicit delivery for?
#
cwebber2 or are there other things too?
#
puckipedia I think it's mostly followers?
#
saranix just consolidation if there is more than one to on the same server
#
cwebber2 if we can make this endpoint for just followers, and everyone is happy with it
#
cwebber2 we can ignore the backend database influence
#
cwebber2 Gargron: this one specifically https://github.com/w3c/activitypub/issues/242#issuecomment-315631633
#
Loqi [cwebber] Going back to this suggestion I made earlier: > If this is only used for delivery to followers, this endpoint can be simplified considerably. All other recipients could be handled by posting to individual inboxes. I wonder if this could avoid t...
#
puckipedia I still feel like an explicit list is nicer...
#
cwebber2 puckipedia: I like explicit lists too, but we're going to probably have to compromise
#
cwebber2 I think the followers one is probably reasonableish enough of a compromise
#
cwebber2 every server is tracking whom they think their users are following
#
cwebber2 *who
#
puckipedia ... actually, do we have any mechanism for follow /requests/?
#
cwebber2 ?
#
cwebber2 oh
#
saranix nothing to notify a denial...except a Block response perhap. A bit blunt, but...
#
cwebber2 I see
#
cwebber2 yeah I don't think we have an ACK/NACK mechanism
#
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
#
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.
#
cwebber2 oh I guess Gargron is saying they do want a followers uri
#
cwebber2 so I guess we could agree on that and change that
#
cwebber2 that's a pretty easy change to make in the AP spec
#
saranix audience and cc distinguish, no?
#
cwebber2 saranix: this isn't about addressing on the activity itself
#
cwebber2 but rather about how you deliver the activities
#
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
#
cwebber2 ajordan: I'm talking about making that endpoint *only* for "deliver to followers"
#
cwebber2 and you use explicit inbox delivery for everything else
#
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.
#
cwebber2 ajordan: I was quoting Gargron
#
cwebber2 from that issue
#
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
#
cwebber2 https://github.com/w3c/activitypub/issues/242#issuecomment-315631704
#
Loqi [Gargron] >email-style vs Twitter style Another point I'd like to add is the distinction between inbox content which is otherwise not present in ActivityPub. In e-mail, your inbox is stuff people send you personally. In a social network, you have a home fee...
#
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
#
cwebber2 this also might solve the "what's a direct message vs what's in your home feed" thing for orgs like diaspora
#
cwebber2 well
#
cwebber2 I guess I did just suggest that ;)
#
cwebber2 but
#
cwebber2 I was thinking through Gargron's comment.
#
puckipedia cwebber2: tbh inbox delivery should not matter no matter what endpoint you use
#
cwebber2 yeah I guess
#
cwebber2 brb
#
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
#
cwebber2 puckipedia: yes
#
cwebber2 puckipedia: that's a concern of mine as well.
#
saranix wait so you guys aren't talking about this then: https://www.w3.org/TR/activitypub/#public-inbox-delivery
#
cwebber2 and I don't really want to federate block activities.
#
cwebber2 saranix: we're talking about changing that.
#
cwebber2 see the forementioned issue: https://github.com/w3c/activitypub/issues/242
#
Loqi [cwebber] #242 sharedInbox / siteInbox type endpoint (publicInbox, but not just for public posts)
#
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
#
jaywink I like the idea of siteInbox too. If the object is "public" then it will be saying so in the object itself - receiving servers should just ensure to do server side stuff depending on the object addressing
#
cwebber2 jaywink: have you looked at the explicit vs implicit stuff from the issue btw?
#
jaywink when raising the need for publicInbox long time ago it was because diaspora delivers public content to one endpoint and private content to users own endpoint - otherwise siteInbox kinda makes sense
#
cwebber2 jaywink: interesting, thanks
#
jaywink cwebber2: yes
#
cwebber2 jaywink: I'm guessing diaspora doesn't do the inferred delivery thing that Mastodon does, and instead keeps an explicit inbox list?
#
jaywink catching up with emails and chats - spent a week drinking and touristing with friends :D
#
cwebber2 since it was also kind of designed around private posts
#
jaywink cwebber2: yes for private deliveries
#
cwebber2 jaywink: interesting, it does one thing for public and another for private?
#
puckipedia I might look at how much work it'd be to make a sharedInbox as I described it
#
cwebber2 btw as a total aside!
#
saranix puckipedia: now your spam filtering idea makes sense. I like it!
#
cwebber2 btw I don't know if I've said it recently in here
#
jaywink cwebber2: it delivers public content to server once "/receive/public" and private to each user individually "/receive/people/guid"
#
cwebber2 but I really appreciate the discourse we've had in this group lately
timbl joined the channel
#
cwebber2 I feel like we've been really working through things well, even when it comes to things like this, which is probably the trickiest topic we've hit
#
cwebber2 so, thanks everyone
#
cwebber2 jaywink: okay cool, thanks for the clarification... a hybrid approach
#
cwebber2 jaywink: how does it store it though?
#
cwebber2 once it's delivered, is the public content "interleaved" via inference via followers
#
jaywink I like that s2s delivery was finally discussed properly :) pity ld-sigs doesn't seem to be the way to go, but if http signatures will end up in spec I would be super happy. it would be so important to specify one and only one way to do it. otherwise sites will not interop
#
cwebber2 or is it, you received it via public delivery, it gets tacked onto your inbox/stream
#
xmpp-social [ajordan] I second what cwebber2 just said
#
cwebber2 jaywink: yeah I think we're starting to see convergence on http signatures
#
cwebber2 I'd like to see linked data signatures explored eventually too but
#
cwebber2 I think at least that will be of big help to settle on
#
jaywink cwebber2: diaspora is a relational db, posts are all stored in the same DB and just pulled out via the web view when needed by filtering
#
puckipedia ah, so Twitter/Mastodon style
#
jaywink db == db table
#
cwebber2 jaywink: so if we have a timeline of user A posts item A1, then A2, then I subscribe to user A
#
cwebber2 will I see their posts "backfilled" into my timeline?
#
cwebber2 or only after subscription?
#
puckipedia I think the former
#
jaywink public content, yes you can browse past psots. private, no, because there is a "visibility" object created when the content appears
#
jaywink so, both ;)
#
cwebber2 jaywink: interesting
#
cwebber2 jaywink: the visibility link basically links object -> viewer?
#
jaywink this is how my own socialhome project works too
#
jaywink yes
#
cwebber2 jaywink: okay. so we're seeing another example of a special case on followers.
#
cwebber2 jaywink: cool, thanks, I'm going to annotate my previous post
#
jaywink server architecture seems to be affecting these things a lot from reading chat logs and emails :P
#
cwebber2 yep
#
cwebber2 so, the *main* point against the followers thing to me still
#
cwebber2 is the federation of blocks.
#
cwebber2 but
#
cwebber2 maybe if someone is effectively no longer subscribed to you
#
cwebber2 they should know
#
cwebber2 I dunno.
#
puckipedia hm. Depends on how you want AP to be used
#
cwebber2 I'm very mixed in my feelings on this
#
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.
#
cwebber2 puckipedia: yeah, I think you're right
#
jaywink a blocked user will likely know they're blocked in all networks except the current federated ones where blocks are not federated (like diaspora, where there doesn't even exist a block, more of an ignore)
#
puckipedia jaywink: good point, an AP block feels more like an ignore
#
cwebber2 hm yeah
#
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
#
cwebber2 also, in general, the kinds of posts people post to followers aren't the things I'm most worried about someone I've blocked seeing
#
jaywink personally I wouldn't send a notification to a local user who gets blocked in my instance. that would feel weird :P even if it was federated
#
cwebber2 those things are *often* also public
#
cwebber2 in diaspora, they always are
#
xmpp-social [ajordan] You could *guess* it was because of a block but wouldn't be sure
#
cwebber2 in mastodon, you can choose for them to not be
#
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
#
cwebber2 ajordan: I think you could still infer information from that
#
cwebber2 it's no better to me than "federate a block but don't expose it in the ui"
#
puckipedia and I really don't like the idea of federating a Block into a weird vague server-inbox
#
cwebber2 yeah I *really* don't like that either
#
cwebber2 maybe we should be making the decision
#
xmpp-social [ajordan] puckipedia: because we've got pushback from Mastodon on that (to be clear that's the approach I'd prefer too)
#
cwebber2 that Block really means ignore incoming content from that person
#
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
#
cwebber2 I think we also can't stop mastodon from federating blocks
#
cwebber2 mastodon is going to do it, probably, even if I think the majority of this channel seems to prefer not to do that
#
jaywink one option is to not adopt "siteInbox", keep "publicInbox" and mastodon does it as an internal extension. This should not hurt delivery, mastodon would have to deliver to followers with no "siteInbox" directly to their inboxes
#
cwebber2 jaywink: or, followersInbox
#
Gargron i was actually gonna ask about how to implement follow requests
#
cwebber2 Gargron: yes, does mastodon have an option for follow ack/nack?
#
Gargron in ostatus i was using request-friend->person, authorize->request-friend->person vs reject->request-friend->person
#
cwebber2 oh!
#
cwebber2 actually, I think we might have the right tools in activitystreams to do it
#
cwebber2 Accept and Reject
#
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
#
cwebber2 ajordan: what about using Accept and Reject for this, what do you think?
#
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
#
cwebber2 we'd have to amend AP to basically include the ack
#
cwebber2 but I think I'm good with this
#
puckipedia should we notify on a reject?
#
cwebber2 yes
#
cwebber2 probably?
#
cwebber2 well maybe, SHOULD
#
cwebber2 or MAY
#
saranix ask the user
#
cwebber2 yeah
#
jaywink how would it even be possibly to deny a follow to someones public content? ;)
#
cwebber2 if a server never gets a reply
#
xmpp-social [ajordan] cwebber2: ah yeah
#
cwebber2 "don't call us, we'll call you" *never hears back*
#
xmpp-social [ajordan] I don't know the vocabulary as well as I could
#
cwebber2 this is interesting
#
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"
#
cwebber2 Gargron: how do you feel about the problem of letting bad actors know about your blocklist as a way to incite more attacks?
#
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
#
cwebber2 Gargron: it's something I worry about
#
cwebber2 Gargron: well... I dunno, in an ideal world, more people self-host
#
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
#
cwebber2 I think we can't assume admins are all benevolent people
#
xmpp-social [ajordan] ^^^
#
cwebber2 Gargron: in mastodon?
#
Gargron yes
#
cwebber2 Gargron: interesting
#
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
#
cwebber2 okay, we can also do this.
#
puckipedia I bet /someone/ has set up a Mastodon instance with that
#
cwebber2 here's another option
#
cwebber2 whether or not to federate a Block is up to the implementer
#
cwebber2 and we include a guide in the AP spec that explains the tradeoffs of doing so.
#
Gargron the worst thing if blocks are not implemented is that the block starts behaving like an ignore.
#
cwebber2 Gargron: you mean, if they aren't implemented to federate?
#
cwebber2 yeah
#
jaywink puckipedia: a server who has a blocking user should probably still reject the content from blocked users
#
cwebber2 so I'm starting to narrow in on a feeling on what we should do, and I wonder how people feel about this
#
Gargron filtering incoming content is a non-problem
#
puckipedia correct. but they could then still view that post
#
cwebber2 - we should switch publicInbox to followInbox
#
cwebber2 make it for follower-delivery only, everything else goes to an actor's inbox
#
cwebber2 *and*
#
cwebber2 - we switch the Block section away from saying SHOULD NOT federate, and instead include an informative note explaining the tradeoffs to doing each
#
cwebber2 and let implementers decide
#
Gargron i agree with 2nd but
#
cwebber2 as Gargron said, worst case is that Block acts more like Ignore
#
jaywink hmm... the point of "publicInbox" was to deliver "to the server". making it a "followerInbox" would indicate it's for senders followers only
#
Gargron i dont think you can have an endpoint that decides on delivery target like that without examining to/cc
#
cwebber2 jaywink: maybe should be renamed but it's still to deliver to the server
#
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
#
jaywink Gargron++
#
Loqi gargron has 4 karma
#
cwebber2 jaywink: the reason why not just publicInbox is that Mastodon has the option to deliver to followers but not make a post public
#
saranix sharedInbox - use the envelope to determine delivery
#
Gargron ^
#
cwebber2 okay I'm fine with that
#
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
#
cwebber2 but
#
jaywink cwebber2: but diaspora style systems post public content probably as the main thing ;)
#
cwebber2 the problem is
#
cwebber2 the envolope might not tell you everything
#
cwebber2 it should only be used for followers, and individual actors
#
cwebber2 other collections, like my "Friends" or "Family" collection
#
cwebber2 I have to explicitly deliver myself
#
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
#
cwebber2 Gargron: you might not have access to the collection
#
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
#
cwebber2 ??
#
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
#
cwebber2 are we requiring implementers implement bloom filters????
#
puckipedia I think that shouldn't be in the spec
#
cwebber2 I don't think so
#
Gargron yeah idk
#
saranix why isn't there a server key?
#
puckipedia saranix: ActivityPub has no concept of a server
#
saranix and server inbox...
#
cwebber2 Gargron: so okay
#
saranix yeah but all the existing protocols Zot,diaspora, etc... do
#
cwebber2 sharedInbox, clearly we can use that to deliver to individuals and followers
#
cwebber2 Gargron: but not the rest of the collections
#
Gargron okay
#
Gargron yes
#
cwebber2 okay
#
Gargron i believe technically you could do other collections as well as long as you track their semantic meaning somehow
#
cwebber2 Gargron: it's very tricky... let's not assume we can for now
#
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
#
cwebber2 Gargron: here's an example why not
#
Gargron same could be done for other collections that are linked from somewhere
#
saranix I'm coding shareInbox in right now... for individuals only
#
cwebber2 remember when Google+ came out and they were advertising circles (yeah I know, stealing Diaspora's aspects idea)
#
cwebber2 they had this ad:
#
cwebber2 and i think it's a problematic ad btw
#
cwebber2 basically someone is moving someone from their circles of "weird people" to "close friends" and eventually they bet bumped to the person's partner
#
cwebber2 well
#
cwebber2 you don't want to share who's in your weird people group ;P
#
cwebber2 so some collections may not be easy to track who's in them externally
#
xmpp-social [ajordan] Hahahaha I remember that ad
#
Loqi awesome
#
cwebber2 anyway
#
cwebber2 revised proposal:
#
xmpp-social [ajordan] Loqi: not really
#
xmpp-social [ajordan] q+
#
cwebber2 - we should switch publicInbox to sharedInbox; make it for addressing only to followers and individuals on to/cc
#
cwebber2
#
cwebber2 *and*
#
cwebber2 - we switch the Block section away from saying SHOULD NOT federate, and instead include an informative note explaining the tradeoffs to doing each
#
cwebber2 is this good (enough)?
#
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/
#
cwebber2 ajordan: if they get a federated block, and they're the kind of server that does/deals with federating blocks
#
cwebber2 they start filtering
#
cwebber2 if not, then they don't filter follows
#
cwebber2 and anyway, you can't force a server to filter anyway
#
cwebber2 so it's "advisory"
#
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
#
cwebber2 I mean, I still think you're "blocking" side effects and receiving information from that user
#
cwebber2 I dunno, how would you display it differently anyway?
#
puckipedia "ignore user" vs "block user"
#
xmpp-social [ajordan] yes
#
xmpp-social [ajordan] the distinction is important
#
cwebber2 well ignore does a bit more than ignore
#
cwebber2 because it also blocks side effects
#
cwebber2 like likes, etc
#
cwebber2 and replies showing up in a replies collection
#
xmpp-social [ajordan] ughh yeah. right
#
jaywink cwebber2: proposal sounds good ?
#
cwebber2 argh oh no, did we never capture "replies" in activitypub
#
cwebber2 because that's def something we want/need
#
cwebber2 it could be an extension but... /me files issue
#
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
#
jaywink isn't there an inReplyTo or something?
#
puckipedia jaywink: yes, but that's the other way
#
cwebber2 ajordan: you're already delivering them to them possibly
#
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
#
cwebber2 ajordan: since you have no control over how that server operates, once you deliver to this sharedInbox, that server could ddecide to not filter it anyway even if they get a Block/etc
#
cwebber2 well
#
cwebber2 okay
#
puckipedia mmmmmghhhhh I really really want to be explicit about who to deliver to...
#
cwebber2 you know what!
#
cwebber2 there's another way to do this.
#
puckipedia I feel like maybe we should make it a SHOULD deliver to those and only those
#
cwebber2 without federating blocks
#
jaywink puckipedia: adding a sharedInbox doesn't mean you can't deliver explicitly
#
cwebber2 hold up
#
cwebber2 what about this idea
#
xmpp-social [ajordan] cwebber2: right, I was just about to bring that up
#
xmpp-social [ajordan] q+
#
cwebber2 Block basically works like Ignore / side effect blocking
#
cwebber2 and you can send a Reject of their Follow, even after an earlier Accept
#
cwebber2 to filter them out again
#
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
#
cwebber2 ajordan: oh really?
#
cwebber2 ha
#
saranix list of ids, not inboxes
#
cwebber2 I have to say
#
xmpp-social [ajordan] lol ya and I think I decided against it for some reason
#
cwebber2 I'm not super excited about sharedInbox as much as I like followInbox ;p
#
cwebber2 I feel like following should be a special case
#
puckipedia saranix: mh, I mean in the style of e.g. "please send this object to user A, B, C specifically"
#
cwebber2 to/cc/etc should really be explicit delivery
#
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
#
jaywink cwebber2: how would you deliver content to a whole server without something like publicInbox/sharedInbox?
#
cwebber2 puckipedia: I know you want explicit delivery but
#
cwebber2 jaywink: I see, you mean to put something in their public stream
#
xmpp-social [ajordan] does anyone want to hop onto a Mumble call?
#
cwebber2 the public federation stream
#
cwebber2 ajordan: I feel like maybe we ought to at this point
#
puckipedia one sec
#
jaywink well, independent of how it is tstored :)
#
cwebber2 ajordan: puckipedia: jaywink: Gargron: saranix: y'all got time for a Mumble call?
#
cwebber2 we're really close to having this sorted I feel
#
jaywink but basically "here is a public post - do whatever you want with it"
#
saranix no mic
#
jaywink damn, sorry, I've never used the mumble thing yet and it's kinda late, need to bed soon :(
#
cwebber2 jaywink: ok np
#
cwebber2 I feel like we do almost have this
#
saranix jaywink: "here is a post involving ids that list you as a caretaker, please deliver to them however you do"
#
jaywink saranix: well, it wont be addressed to anyone except public ;)
#
saranix you won't deduplicate private posts?
#
saranix kind of a waste...
#
jaywink talking strictly public content here
#
saranix you are, not the rest of us
#
cwebber2 <Gargron> because what if i target at all my followers, but also cc public
#
jaywink yes, but it's a use case for sharedInbox :)
#
cwebber2 maybe sharedInbox could only be for followers and public only ;P
#
saranix exactly!
#
saranix no cwebber2!
#
saranix that would be bad
#
puckipedia tries to mumble but got a shitton of stuff open
#
cwebber2 saranix: what wai
#
saranix wastes 90% of use case it would be used for
#
cwebber2 what really?
#
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
#
jaywink wasn't private delivery to followers the reason Gargron raised this anyway?
#
jaywink otherwise publicInbox would be fine
#
jaywink maybe lost the point of discussion and should bed :D
#
saranix In my usecase "followers" is irrelevant... it's "who has permission to see it"
#
jaywink for private content isn't that the same thing?
#
saranix yeah I guess
#
cwebber2 saranix: you can still deliver to normal inboxes
#
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
#
cwebber2 saranix: you don't need to do do to: a, b, c
#
cwebber2 saranix: oh
#
cwebber2 you're saying you *never* have followers?
#
cwebber2 oi
#
saranix I'm saying most users don't share their follower list
#
saranix and it is default
#
cwebber2 saranix: if we move to always having an Accept after a Follow
#
cwebber2 your server would knwo
#
cwebber2 know
#
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)
#
cwebber2 saranix: anything on bto should be delivered explicitly
#
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
#
cwebber2 saranix: ok, that goes back to explicit vs implicit lists though
#
saranix popular.example DOES NOT see someother.example's bto's, only the ones that share that particular sharedInbox
#
cwebber2 also no need to shout :)
#
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
#
cwebber2 https://public.etherpad-mozilla.org/p/activitypub-implicit-explit
#
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
#
jaywink oh that was me just having a quick look. to bed now *waves*
#
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?
#
cwebber2 Gargron: do you need a shared endpoint, really, other than for just followers + public
#
cwebber2 Gargron: we could really simplify things by limiting it to just those things ;_;
#
xmpp-social [ajordan] cwebber2: q+
#
cwebber2 :)
#
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
#
cwebber2 q+
#
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}
#
cwebber2 I'll need to go through that etherpad again before the socialwg call
#
cwebber2 but whew!
#
cwebber2 exhausting but productive :)
#
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!
#
cwebber2 ajordan: thank you :)
#
cwebber2 puckipedia: :D good night!
#
puckipedia I put a few notes in here about the pinned post: https://github.com/swicg/general/issues/12#issuecomment-315644330
#
Loqi [puckipedia] My suggestion would be to have it be a set of `@id`, so in a JSON-LD context kinda like this: ``` { "@context": { "pinnedObject": { "@id": "as:pinnedObject", "@type": "@id" } } ``` and it'd just refer to notes inside. ...
#
puckipedia well there's the entire note
#
cwebber2 haha
#
Loqi hehe
#
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
#
ajordan cwebber2++ for all the spec shepherding you've been doing recently
#
Loqi cwebber2 has 92 karma
#
Gargron cwebber2++
#
Loqi cwebber2 has 93 karma
#
ajordan Gargron++
#
Loqi gargron has 5 karma
#
ajordan puckipedia++
#
Loqi puckipedia has 11 karma
#
ajordan for sitting through that call
#
ajordan man this stuff is confusing
#
saranix https://distbin.com/activities/c6274d2e-f5c9-4fdd-89b2-057df5333872
#
saranix ate my formatting unfortunately
#
ajordan okay, summary: https://github.com/w3c/activitypub/issues/242#issuecomment-315645158
#
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...
#
ajordan if everyone present on the Mumble call could please review that'd be great
#
ajordan Gargron cwebber2 puckipedia
#
ajordan saranix: I'll relay your comment in just a sec
#
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.
#
Loqi [puckipedia] I would vote for specifying each and every recipient, as servers may implement the addressing slightly differently, and a server can't feasibly look through a collection containing e.g. thousands of objects stored remotely. Alternately, in a perfect ...
#
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
#
ajordan saranix: https://github.com/swicg/general/issues/12#issuecomment-315645652
#
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++
#
Loqi ajordan has 14 karma
#
ajordan sure
#
ajordan I responded too
#
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