#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
#
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
#
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
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 :)
#
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 )
#
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
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
#
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?
#
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
"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
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
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
#
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
#
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
#
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...
#
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
#
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
I guess I did just suggest that ;)
#
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
#
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.
#
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
#
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
so, the *main* point against the followers thing to me still
#
cwebber2
is the federation of blocks.
#
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
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
probably?
#
cwebber2
well maybe, SHOULD
#
saranix
ask the user
#
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?
#
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
- 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
#
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
#
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
#
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
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
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
- 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
#
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?
#
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?
#
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
#
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
#
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+
#
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}
#
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
#
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
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...
#
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
#
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
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