#social 2017-07-12

2017-07-12 UTC
timbl joined the channel
#
xmpp-social
[ajordan] https://www.w3.org/wiki/SocialCG/2017-07-12 is empty
#
xmpp-social
[ajordan] cwebber2, aaronpk: ^^^?
#
xmpp-social
[ajordan] Telecon tomorrow?
#
aaronpk
Oops yes was planning on it
#
xmpp-social
[ajordan] Do we have an agenda somewhere other than that page? If there isn't any clear purpose I have other things I'd rather do during that time
prtksxna, prtksxn__, xmpp-social, timbl, cwebber2 and jmcbray joined the channel
#
cwebber2
yeah we should probably have a meeting?
#
puckipedia
hm, that's in about 45 mins right?
#
cwebber2
but deppends on if people show up I guess? :)
#
cwebber2
puckipedia: might be cool to explain all the things you've done with Koreg
#
puckipedia
yeah, thought of that
#
puckipedia
and also maybe the extension I added (there's 2 or 3 or so)
#
cwebber2
absolutely
#
cwebber2
maybe sandro would like to share a followup to last week's embedding convo too
#
puckipedia
currently in a train back home
#
aaronpk
can i throw a quick shout-out about websub implementation reports in at the beginning?
#
cwebber2
aaronpk: yes please
#
tsyesika
I'm getting horrible echo
#
cwebber2
scribenick: puckipedia
#
ben_thatmustbeme
sandro, yes, it caused a really bad echo when you were unmuted
#
cwebber2
trackbot, start meeting
#
trackbot
is preparing a teleconference.
RRSAgent joined the channel
#
trackbot
RRSAgent, make logs public
#
RRSAgent
I have made the request, trackbot
Zakim joined the channel
#
ben_thatmustbeme
waves to Gargron
#
Zakim
ok, trackbot
#
trackbot
Zakim, this will be SOCL
#
trackbot
Meeting: Social Web Working Group Teleconference
#
trackbot
Date: 12 July 2017
#
tsyesika
present+
#
aaronpk
present+
#
cwebber2
present+
#
puckipedia
present+
#
cwebber2
scribenick: puckipedia
#
Gargron
present+
#
cwebber2
topic: socialwg updates / websub implementation report
#
cwebber2
found aaron cut out for just a moment
#
puckipedia
aaronpk: websub: there are now two or more implementation imports for each role (pub/sub/hub)
#
Gargron
i've been recently thinking about sticking HTTP signatures on top of WebSub subscription requests so the hub could attach a user identity to a callback URL (optionally)
#
cwebber2
Gargron: I'll add this as a topic to the agenda
#
puckipedia
aaronpk: no new reports from the implementations in the GNU social space, Mastodon would be really nice to get
#
sandro
s/Gargron:/Gargron,/
#
Gargron
it's not so much that a user identity is useful because a callback URL is instance-wide but because there is no other concept of "instance" than the domain field on a user, that's basically what i want to use it for
#
ben_thatmustbeme
go to websub.rocks and test there
#
puckipedia
aaronpk: we need more reports to go further through the process
#
ben_thatmustbeme
(that part cut out of me)
#
Gargron
mastodon is on pubsubhubbub 0.4
#
ben_thatmustbeme
Gargron, it should be the same, we worked hard to make sure any pubsubhubbub is websub compliant
#
ben_thatmustbeme
for 0.4 anyway
#
puckipedia
aaronpk: about PuSH 0.4, it should be compatible with WebSub
#
Gargron
i am pretty sure websub.rocks worked with mastodon since the very start
#
aaronpk
people are dropping out for me too... so i wonder if my internet is having trouble today
#
puckipedia
Gargron: I don't know how important it is, the application of this is limited. There's a spec called HTTP signatures, came up before related to ActivityPub
#
puckipedia
q+
#
Zakim
sees puckipedia on the speaker queue
#
puckipedia
Gargron: we can reuse the keys to do salmon keys, and for access control. for WebSub subscriptions, it'd be nice to link the subscriptions to instances or servers
#
puckipedia
Gargron: domains are [side effects], ... domain whitelisting, blacklisting. somehow link a callback url to the instance it comes from.
#
puckipedia
cwebber2: if you're adding signatures via http signatures, it'd be backwards compatible
#
puckipedia
Gargron: it'd be an extra piece of information, and wouldn't be required
#
puckipedia
aaronpk: why isn't the URL itself enough to use? the domain is part of the callback url, right?
#
puckipedia
Gargron: not needed, it can be on other domains, etc, be forwarded, and instances can be on subdomains and have forwarded the webfinger from the root
#
cwebber2
nice job scribing puckipedia :)
#
puckipedia
Gargron: we only send private statuses to instances if their domain is approved. but the callback url can be different. Domains that have a different host don't receive the private statuses
#
Zakim
sees puckipedia, sandro on the speaker queue
#
Zakim
sees puckipedia, sandro on the speaker queue
#
cwebber2
ack puckipedia
#
Zakim
sees sandro on the speaker queue
#
cwebber2
scribenick: cwebber2
#
cwebber2
puckipedia: mostly in response to http signatures; I recently implemented server to server authorization on Koreg, which uses json web tokens with the key behind it. And I think it might be a slightly better option because it's already in RFC, whereas http signatures might expire. As for federation of websub urls, it sounds a bit hacky to use a random identity, for example a first follower
#
cwebber2
Gargron: yes you're right, it's hacky, but that's because this hasn't been a use case in the original protocol designs. They didn't consider an instance (user?) to be an entity by itself and have any agency. Doesn't have to be a random user, can be the first user that followers, but if different user in the future there has to be another method because salmon, etc. Re: JWT I dunno, but HTTP Signatures are dead simple to implement and
#
cwebber2
have that going for them
#
aaronpk
https://tools.ietf.org/html/draft-cavage-http-signatures-06 is the signature spec we're talking about right?
#
cwebber2
puckipedia: yeah, the way I solved that is not have a single centered subscription for the entire server, because that's mostly how activitypub works. so websub, ostatus support is kind of a side effect of the implementation
#
cwebber2
Gargron: wait that means if one server has one message, it has to send the message 20 times?
zatnosk joined the channel
#
cwebber2
puckipedia: yes, but also usually activitypub works on the other way, like you specifically determine which users to send it to, which can be a collection of all your followers, so the server pushes out the messages rather than a server subscribing to and endpoint that delivers the messages of that user
#
Zakim
sees sandro, cwebber on the speaker queue
#
cwebber2
Gargron: yeah you're right, but it's still the same model.. the original server looks at the followers collection, then delivers to them. public endpoint though is shared by all users. That's a concern of mine though becaus if you scale that up that's a lot of http requests duplicated
#
cwebber2
puckipedia: yeah I just realized that doesn't work for websub subscriptions, so it doesn't work for that case. has to be addressed to the public collection for it to be used
#
cwebber2
Gargron: yes, in fact that's a bit problematic... assuming you have the same message, the server would still use the same info of who the users are. So... it's not very optimized, I dunno
#
Zakim
sees sandro, cwebber on the speaker queue
#
cwebber2
ack sandro
#
Zakim
sees cwebber on the speaker queue
#
cwebber2
sandro: so two kind of different comments, this is cleanly a websub extension? we're not talking about a websub modification, this is an extension that the different components could use if they want to
#
puckipedia
scribenick: puckipedia
#
cwebber2
thx puckipedia :)
#
puckipedia
sandro: this is no reason to slow down websub, right?
#
puckipedia
Gargron: indeeds
#
puckipedia
sandro: I don't know http signatures very well, but this doesn't solve distribution. You still have to look up the key, can't you just check the hub url?
#
puckipedia
Gargron: not quite. the http signature contains the key id, algorithm, and signature (concatenation of a specific set of headers in an order). the key id can be anything. In case of mastodon, the key id is the account resource identifier
#
puckipedia
Gargron: which is most likely to be in the database. So you can just look it up in the database. if it isn't equal, you can look it up remotely
#
puckipedia
sandro: by the same mechanism of storing the public key, you could also store the hub url
#
puckipedia
sandro: your extension would be an add an 'on behalf of'. you could also add a webfinger field to where the subscriptions should be sent
#
puckipedia
Gargron: there's no connection between webfinger and signature url. The websub subscription contains a callback url, it's not in webfinger
#
puckipedia
Gargron: the hub server is supposed to validate the url. but, that's nothing to do with who's doing the subscription. and that's the key of what http signatures offers. it's not enough to say it's 'on behalf of'. what if a malicious user sends the request? That's what http signatures are for
#
puckipedia
sandro: would someone want to raise an issue to [explore how to solve this issue?]
#
puckipedia
cwebber2: sounds like you just volunteered, sandro :)
#
Zakim
sees cwebber on the speaker queue
#
cwebber2
ack cwebber
#
Zakim
sees no one on the speaker queue
#
puckipedia
cwebber2: so one thing I wanted to understand is slightly [tangental], the purpose of the publicInbox endpoint is to avoid the problem of where you have to do a lot of delivery to a lot of users
#
puckipedia
cwebber2: we did this in request of diaspora, do you think there are other cases that are not the publicInbox case that aren't handled by that delivery mechanism, that we're really missing?
#
puckipedia
Gargron: I understand that ActivityPub is very general, in the way it was created with the client API as well, it's oriented to writing messages to specific users
#
puckipedia
Gargron: in the case of adding activitypub, we won't get a whole new addressing. it's delivered to the followers and the people mentioned, in the case of public posts and private posts
#
puckipedia
Gargron: if I make a private post, would my server have to send 15000 requests to all servers? my view is that the publicInbox would be used for private posts too. the server would use its knowledge of the followers to do delivery to the specific individuals
#
puckipedia
q+
#
Zakim
sees puckipedia on the speaker queue
#
puckipedia
cwebber2: my impression is where thing only would be used publicly isn't right, my issue is how we'd addrses this
#
puckipedia
cwebber2: you'd have to rely on the other server having a good sense of followers
#
cwebber2
ack puckipedia
#
Zakim
sees no one on the speaker queue
#
cwebber2
scribenick: cwebber2
#
cwebber2
puckipedia: mostly a response to the delivery mechanism. Wouldn't it be possible to have a public inbox and also a list of people to deliver to on that server
#
cwebber2
Gargron: usually a server should keep track of followers, so there's already usually an internal follower list used for doing the home feeds of people, so seems like that info is already tracked
#
cwebber2
puckipedia: in the way that I implemented and think of how it should be? your inbox is basically your home feed, so every message that goes to followers of a person, you're addressed to that post. I don't really trust the collections on other servers, I don't use that information. I don't use that to determine if you follow someone. For example, if you block someone, it shouldn't be delivered to that person
#
cwebber2
Gargron: mastodon takes a slightly different approach, blocks are delivered as a salmon slap, but it's just to notify the server so it can update its own follower/following lists to prevent the user from seeing
#
Zakim
sees cwebber on the speaker queue
#
puckipedia
scribenick: puckipedia
#
cwebber2
ack cwebber
#
Zakim
sees no one on the speaker queue
#
puckipedia
cwebber2: so partly one way this might tie in is, I agree with puckipedia with that, specifically, the server it's delivering list, and I think a public inbox that also lists which people to deliver it to, instead of a server keepign track of who it should deliver to
#
puckipedia
cwebber2: you might not want to expose a block activity with a person. you may be federating a block list, without sending that to hostile people. another one, used as an unfortunate [??], there's been this conversation about 'advisory privacy' type things [?]. The challenge of ostatus private messages is because of a lack of explicitness
#
puckipedia
cwebber2: I worry that would go away if you post to a publicInbox and not specifying who it'd go to
#
puckipedia
Gargron: there's concerns about synchronizing follower lists, if e.g. a block has not been federated properly, and the person shouldn't be following the other anymore
#
puckipedia
Gargron: the main problem of the "leaky" privacy is the fact that the status of a message being private or not is bolted on, and not part of the protocol itself
#
puckipedia
Gargron: if the parser doesn't know what to do with the bolted on private message it defaults to public. this will be solved by ActivityPub, as public/private is part of the protocol
#
puckipedia
Gargron: the greatest approach would be to explicitly state which places a message would go to, and each place storing which users were targets. however, it's a problem of data modelling. storing a list of thousands of people that are unique for each individual message would be an explosion of storage and complexity. the way Mastodon models is that there are messages, followers, and your home feed is a sum of the messages of your followers
#
puckipedia
cwebber2: I was wondering if there was a publicInbox which has a list of audiences, would that be satisfactory? e.g. being explicit being a dealbreaker
#
puckipedia
Gargron: what would the remote server do with the explicit information? For notifications, we could store it. But messages haven't been made to be put in 12k people. as for home feeds, they're based on follower status. even if you get a list of targets, while it is possible to append it to the home feed in redis (cache layer), as soon as that expires
#
puckipedia
Gargron: e.g. being gone for 2 weeks, it has to be rebuilt based on the database. so those messages would be lost
#
puckipedia
cwebber2: I'm starting to understand the database side. Seeing how puckipedia and I implemented it, the inbox is a large collection, an ordered list you are tacking items onto. but my impression is, what you're saying, is that in MAstodon there's no such 'inbox' structure, you have each post with who its followers are, you build the inbox from that
#
puckipedia
cwebber2: so if you unfollow someone, old statuses disappear too?
tantek joined the channel
#
puckipedia
Gargron: there's two things: accounts, and statuses. Accounts follow other accounts, and are followed by others. this is how it's encoded into and from OStatus
#
puckipedia
Gargron: there is no concept of a polymorphic table you store the entire inbox into
#
tantek
waves
#
puckipedia
Gargron: so yeah, that's mainly where the project comes from. The system wasn't build for this massive home feed for every user that stores each thing for each user
#
puckipedia
cwebber2: it'd be very complicated to calculate, right? would you think to moving a collection for each user would be maybe more efficient?
#
ben_thatmustbeme
side note, Gargron would love to get your thoughts / feedback on this https://discourse.joinmastodon.org/t/federation-with-indieweb/434
#
puckipedia
Gargron: it's pretty efficient. when a status appears, we trigger so-called FanOutOnWrite. it looks at the followers of the account who posted it (local or remote), for each follower we put the message on their home feed, the write-layer cache, a redis sorted set that contains the IDs of the statuses on each user online for the last 2 weeks
#
puckipedia
Gargron: the expensive query is when the feed is cleared out completely, when we have to look at all the messages of the people they're following
#
Zakim
sees no one on the speaker queue
#
puckipedia
cwebber2: I see why the DB structure incentivizes a certain pattern. I feel like I haven't completely thought it through. so, well, I don't know if I have anything else
#
tantek
tries a new set of earphones
#
aaronpk
my audio is pretty bad today so sorry i'm not saying much
#
cwebber2
tantek I pulled you into the room then dropped you out because of typing noise :)
#
puckipedia
Gargron: to reiterate, that system is kinda really efficient, when I was building Mastodon, I was researching how other systems implemented it. there's an article on a blog called something dot scalability. Twitter shared something about the architecture. the method I implemented is how Twitter does it as well, it's storage efficient and also very fast
#
tantek
oops sorry. you pulled me in before I could self-mute :)
#
puckipedia
Gargron: you can also do advanced filtering on the home feed
#
tantek
cwebber2 I have a noisy "silent" daskeyboard for the furious typing hacker noise :)
#
puckipedia
cwebber2: I suggest we stew on these structural differences and what it means and move on to further topics
#
Zakim
sees no one on the speaker queue
#
tantek
reads the agenda
#
cwebber2
scribenick: puckipedia
#
cwebber2
scribenick: cwebber2
#
cwebber2
puckipedia: Kroeg is pronounced like "koough"(?) which is a Dutch pun on PubSub
#
tantek
is once again surprised at how nice and clear people's voices are
#
puckipedia
(Pub)
#
cwebber2
topic: Kroeg implementation of ActivityPub
#
tantek
sandro you sound so much better on Mumble than Webex
#
cwebber2
Gargron: may I ask how far you are in your implementation?
#
tantek
present+
#
cwebber2
puckipedia: I think I've implemented everything, and I think I added useful extensions for clients. I added two extra endpoints
#
cwebber2
puckipedia: the first endpoint is a settings endpoint to get a url from where you can do changes to settings, eg changing passwords and etc. I've moved it into an endpoint that's basically a web page
#
cwebber2
cwebber: why not just put it on the user's profile?
#
cwebber2
puckipedia: because endpoints are public urls, and you can't get browser to explicitly use a specific authorization header... so in our case it gives the user 10 minutes of time to change settings
#
ben_thatmustbeme
sandro best i have have been able to find is pronounce it sort of like "crew-g" or "crew-ig"
#
cwebber2
puckipedia: the other endpoint is basically all your relevant objects relevant to other objects... eg all the objects that are attributed to you which also have as object the (?) so you can get all the Likes and Announces of a specific post
#
ben_thatmustbeme
from audio clips on the internet
#
cwebber2
puckipedia: it should also probably show all the Undos of those objects but that may come later
#
cwebber2
puckipedia: so a client could use that to show that you've already liked a specific object, so you can undo that like, mainly because AP has undos of everything instead of unlikes, etc
#
tantek
attempts to read backlog
#
cwebber2
puckipedia: oh, and I added a list of blocked users to a user object, so you can look back at what things are blocked, so you can't see in the spec how that should work, so that's kind of interesting
#
cwebber2
puckipedia: it doesn't have any special features yet, but I'd like to add things like deferred authorization to specific servers, you can not tell...
#
cwebber2
cwebber: Any lessons learned from doing the implementation?
#
tantek
reads about WebSub implementation reports
#
tantek
aside: Gargron, it would be great if you could try Mastodon on websub.rocks and submit an implementation report! Any chance of doing that in the next week or two?
#
cwebber2
puckipedia: one weird thing I had was side effects of specific objects... eg user A of server A sends Like to server B on server B, I accidentally handled side effects twice because it was delivered multiple times. So I limited it to only when the user is notified that it gets the side effects
#
Gargron
tantek: i am pretty sure it just works and you could try it yourself with someone's public profile
#
cwebber2
puckipedia: basically, when you follow a user but you do not send that activity to that user you're following, you will not be added to that list of followers, even if you are on the same server but not following that person
#
tantek
Gargron: always better to get a report done by someone *outside* the WG
#
tantek
Gargron: would you be ok with me filing an issue requesting this? That way maybe someone in the Mastodon community could pick it up?
#
cwebber2
Gargron: so I'm trying to make progress in AP in mastodon as well, and the way I'm doing this is adding the json representations of objects first, and it turns out it's kind of complicated. the pull request has been WIP for like 20 days, which is pretty long. some of the roadblocks are eg sensitive content, which I've added a boolean property, and the Tag type, which I've just added a Tag type. What's still problematic is which
#
cwebber2
I have to return Notes from the url structure except when it's reblog, in which case i return an announce, or I start to do Create activities for all of them and Announce for some others
#
cwebber2
internal visibility levels should correspond to to/cc objects. It's not clear how to represent that. It's implementation specific but I'd like help/review. But one thing is when to show Create of the object or just the Object. And this again has to do with the internal storage; there is basically a url structure where you basically retrieve a status. So a status can actually be something like an announce of another note, so either
#
cwebber2
Gargron: which one is the Create, which one is the object, which is the outer or inner?
#
cwebber2
Gargron: so yeah, that's been the main problem. the pull request is on github if you want to review/comment
#
Zakim
sees cwebber on the speaker queue
#
cwebber2
puckipedia: ok so that's quite a bunch
#
puckipedia
scribenick: puckipedia
#
cwebber2
ack cwebber
#
Zakim
sees no one on the speaker queue
#
puckipedia
cwebber2: so one thing I wanted to say is that this challenge of Creates being kind-of as .. activitypub, as a spec comes from pump.io, which had separate create objects. when it started to turn into ActivityPub it was called ActivityPump, written by oshepherd, familiar with the history of this space
#
Gargron
:100:
#
puckipedia
cwebber2: originally, they wanted to remove Create, because it was very artificial. if it's just an object, you may as well ship it
#
puckipedia
cwebber2: the problem is that not everybody agreed with it (at least Evin[?]), you should always have the verb of the Activity, and when you look at someone's feed you should always see activity, some kind of subject, and some kind of object
#
puckipedia
s/subject/actor/
#
tsyesika
I would
#
tantek
we dropped verbs in AS2 by consensus in SocialWG years ago as one of the first simplifications like in 2013? 2014? I'll see if I can look it up
#
puckipedia
cwebber2: so that's the reason the Create activity is there. We talked about this, because webmention doesn't do anything like this. we had talked about removing it, but we got strong pushback from Evin, and from my own implementaion, I wouldn't mind dropping it
#
puckipedia
we resolved to keep it in, and added the whole goofy mechanism that if you drop an object in an outbox it'd be wrapped in a Create activity. some history
#
tantek
s/Evin/Evan
#
Gargron
so outbox should contain create/announce. the IDs would correspond to local statuses, and the status URIs would return the create/announce as well, and nothing would return the notes standalone - would that be fine?
#
puckipedia
cwebber2: not as short as I implied it was going to be. I feel your pain on the create wrapping stuff. if it was just me, we would make it optional. maybe we *should* make it optional, if there's enough implementors
#
cwebber2
scribenick: cwebber2
#
tantek
is going to attempt to dial into his 09:00 PDT telcon on another device
#
cwebber2
puckipedia: I think that the Create is actually pretty useful in some cases, because you get an outbox that is just activities, and each activity contains an object. that kind of IMO makes more sense, because you've got Create, Updates and Deletes. I think if just posting objects I think it would be less clear. I don't think an object is required to have any attributedTo or anything, so I think the actor is the only official way to
#
cwebber2
make the object
#
cwebber2
Gargron: I agree that without the announce activity I think it would be hard to tell how an object was there
#
ben_thatmustbeme
lol, tantek, dual telcon wielding
#
cwebber2
Gargron: in the outbox I definitely agree Create/Announce activities should be there
#
cwebber2
Gargron: but they both currently require an id, and it's not clear that both should be resolvable. but both id should resolve to the actual id of the object, so the question actually becomes when the corresponding user has a unique identifier, if queried by itself should it show the Create/Announce or the actual object. the consistent way its the outbox has the Create/Announce, and if you pull back the Create/Announce and nothing has
#
cwebber2
the Note itself
#
cwebber2
Gargron: but on the other hand what do you do when you have an Announce and instead of the object being embedded, you have only the URI of the thing being announced
#
cwebber2
Gargron: if you go to the id it should give the Create, that would be inconsistent
#
cwebber2
puckipedia: so there are multiple ways to fix this, for example one of the ways you can do it is by having always a url which is the url of the Create activity or the Announce activity, and always have the id inside, and the fragment is inside, you can get the Create around it and store that too, returning only the Note it contains, so you could have a fragment identifier or have a sub-id
#
cwebber2
puckipedia: as far as I can tell from the spec any object with an id should be resolvable
#
Zakim
sees cwebber on the speaker queue
#
cwebber2
puckipedia: so any Create should be resolvable separately
#
Gargron
so.... activity = real id. object = fragment id inside the activity
#
puckipedia
scribenick: puckipedia
#
cwebber2
ack cwebber2
#
Zakim
sees cwebber on the speaker queue
#
cwebber2
ack cwebber
#
Zakim
sees no one on the speaker queue
#
Gargron
if that's what you mean that could work, makes sense
#
puckipedia
cwebber2: fragment identifiers are tricky, because there's no way it can be resolved. Kroeg assumes you can find the top-level object and look through it. that's nice, but not guaranteed
#
puckipedia
cwebber2: fragment identifiers are best used where you have no guarantee you can retrieve it independently. so I would advice each object having a full-fledged identifier
#
puckipedia
cwebber2: one solution is, I'm going to type it up on IRC
#
cwebber2
https://mastodon.example/post/123/create <- "artificially generated" Create object
#
puckipedia
cwebber2: so you cna have your base object, and since Mastodon is generating things from its highly structured database, so you can generate a Create object for that, that's dynamically generated. that'd be the cleanest result for what I understand is Mastodon's design
#
sandro
+1 love/hate fragment ids
#
tsyesika
Wait. How does that handle user generated creates if it's dynamically created on the server?
#
tsyesika
I am probably misunderstanding
#
tantek
has mixed feelings about fragment ids
#
puckipedia
cwebber2: I kind of like fragment identifiers, and I kind of hate them. there's one person here who hates this usage, it can be a bit tricky. If you want people to be able to resolve it the best way is to give it a separate url
#
tantek
likes fragment "ids" for fragmentions: indieweb.org/fragmentions
#
puckipedia
cwebber2: answering tsyesika; say, you had an object like this
#
cwebber2
{"type": "Note", "content": "I'm a note", "author": <gargron_uri>}
#
cwebber2
{"type": "Create", "object": {"type": "Note", "content": "I'm a note", "author": <gargron_uri>}}
#
puckipedia
cwebber2: and if you'd visit /create, it'd be wrapped into something like this:
#
puckipedia
cwebber2: I think that's the cleanest design for Mastodon's case, I wonder how you feel about that, Gargron
#
puckipedia
Gargron: I think that would probably work, didn't [..] want to add additional routes, but that's going to work, it's not the worst thing
#
tsyesika
But this is to prevent having to keep creates in the db right? What if the user makes the create and submits that via the client API?
#
puckipedia
(Gargron: I could probably help with the implementation?)
#
puckipedia
(tsyesika: Mastodon would probably not do the ActivityPub client API?)
#
puckipedia
woops, missed a bit
#
puckipedia
Gargron: in case of the /announce, the url without the /announce would be the remote one
#
tsyesika
ah I see. I'm with you
#
tantek
is a bit lost and unsure that the announce abstraction is needed. or rather, for what use-case is it needed? sorry if I'm being dense.
#
puckipedia
(did I drop? I don't hear anything)
#
tsyesika
I wonder how it'd store remote creates federated them
#
tantek
puckipedia I don't hear anything either
#
cwebber2
{"id": "https://localmasto.example/post/8351", "type": "Announce", "object": {"id": "https://remotemasto.example/post/515/", "type": "Note", "content": "I'm a note"}}
#
puckipedia
. o O ( crickets: *cricketing* )
#
sandro
needs to leave. Bye, all!
#
puckipedia
( seriously, is there anyone speaking? I don't hear anything and my Mumble is not showing anything )
#
tsyesika
puckipedia: chris is
#
puckipedia
reconnects
#
aaronpk
has to leave as well, but sounds like a good discussion is happening so plz continue :)
#
cwebber2
sorry everyone :)
#
cwebber2
thanks everyone :)
#
sandro
hopes folks continue as well
#
puckipedia
cwebber2: my suggestion of the artificial create would be only for the Creates, but for the others they wouldn't have to be dynamically generated. I understand your feeling of ickyness for the particular url structure
#
Gargron
yeah sorry about making this discussion too implementation specific
#
tantek
is happy to keep going despite being on another call
#
tantek
the discussion is very interesting to hear
#
Loqi
[sandhawke] #5 In-Page Social Interactivity
#
ben_thatmustbeme
Gargron: its okay, implementation info is always good
#
tantek
thanks cwebber2
#
cwebber2
trackbot, end meeting
#
trackbot
is ending a teleconference.
#
trackbot
Zakim, list attendees
#
Zakim
As of this point the attendees have been tsyesika, aaronpk, cwebber, puckipedia, ben_thatmustbeme, Gargron, tantek
#
trackbot
RRSAgent, please draft minutes
#
RRSAgent
I have made the request to generate http://www.w3.org/2017/07/12-social-minutes.html trackbot
#
trackbot
RRSAgent, bye
#
RRSAgent
I see no action items
#
cwebber2
thanks for scribing again puckipedia :)
#
cwebber2
puckipedia++
#
Loqi
puckipedia has 7 karma
#
puckipedia
Gargron: so I could probably poke at the ActivityPub implementation for Mastodon
#
Loqi
[Gargron] #3844 Improve ActivityPub representations
#
puckipedia
yeah, got that in front of me
#
puckipedia
lemme see if I still have the local mastodon instance
#
Gargron
saving AP users into db gonna be challenging because while some attributes overlap AP users also need some of their collection URIs stored as well
#
puckipedia
for remote users, you could also just return the ID of the user instead of storing all the metadata
#
cwebber2
Gargron: what do you think of this as a compromise
#
tantek
is now distracted by another telcon
#
tantek
Gargron, do you mind if I ask aaronpk to file an issue on Mastodon requesting a WebSub implementation report?
#
Loqi
[aaronpk] #4173 Please submit WebSub implementation report
#
cwebber2
a public endpoint where you specify specific users to deliver to, but you can also specify collections in there, such as the followers collections of the other server
#
tantek
aaronpk++
#
Loqi
aaronpk has 93 karma in this channel (1378 overall)
#
puckipedia
cwebber2: wouldn't that just be the audience in the object itself
#
cwebber2
puckipedia: hm, yes I guess so, except for bto/bcc
#
cwebber2
maybe bto/bcc should never be delivered on a public endpoint anyway
#
puckipedia
bto/bcc is kinda unclear to me still
#
cwebber2
it could be that the public endpoint behaves differently if it doesn't see the special Public endpoint addressed to
#
Gargron
cwebber2: yeah honestly publicInbox + to: followersURI is what i had in mind
#
puckipedia
wait here's the Mastodon instance I had running locally
#
cwebber2
Gargron: that would probably work. if we're going to do this though
#
cwebber2
we should be clear in the spec
#
cwebber2
so we don't end up with the problem we're having in ostatus
#
cwebber2
where servers are implementing this differently
#
cwebber2
Gargron: could you make an issue on the activitypub issue tracker and describe what you think the right behavior is?
#
Loqi
it is probable
#
cwebber2
in return I'll review your mastodon issue today ;)
#
Gargron
aaronpk: tantek: as i said, websub.rocks/publisher works just fine
#
Gargron
you can enter https://mastodon.social/@Gargron.atom into the field and wait until i toot something
#
aaronpk
Gargron: it's more about having the report on file than whether it works with websub.rocks. we need the PR with the checkboxes https://github.com/w3c/websub/blob/master/implementation-reports/PUBLISHER-TEMPLATE.md
#
aaronpk
that's great that it works tho!
#
aaronpk
isn't mastodon also a hub?
#
cwebber2
Gargron: if you don't have time let me know, I can file the issue and you can correct me
#
cwebber2
if I get what you're suggesting wrong
#
Gargron
mastodon is publisher, hub and subscriber
#
Gargron
and yes feel free to file
#
aaronpk
that's great, that will help a ton to have reports for all the roles
#
Gargron
the hub is advertised in the Atom XML
#
Gargron
all updates are in Atom
#
Gargron
that's the publisher template. the hub one:
#
Gargron
subscribes with a secret are our main thing. don't remember if it works without secret
#
Gargron
ignoring unrecognized params is no problem
#
Gargron
re-subscribing anytime
#
Gargron
unsubscribing is fine
#
Gargron
verification is fine
#
Gargron
lease request is supported, but a min/max range is enforced
#
Gargron
matching content type: yes, full contents: yes, signature: yes, it uses the PubSubHubbub 0.4 signature method, whatever that one was. hmac sha256 on shared secret probably
#
Gargron
sends only a diff
#
Gargron
subscriber:
#
Gargron
expects hub link in atom
#
Gargron
rejects invalid topic URLs
#
Gargron
creates subscriptions fine
#
Gargron
uses a secret (same as above)
#
Gargron
specifies a lease
#
Gargron
callback URL is unique per subscription
#
Gargron
callback URL miiiight be guessable
#
Gargron
unsubscribes
#
Gargron
dunno about the redirect ones or different rel=self
#
Gargron
returns 2xx on delivery
#
Gargron
verifies signature
#
Gargron
and the last ones, yes
#
puckipedia
Gargron: so I'll grab some food, wait for the dependencies to install, then I'll take a peek at the PR about activitypub
#
Gargron
that's all - sorry for spamming the channel didn't expect there to be so many items
#
aaronpk
awesome thanks
#
tantek
Gargron++ thanks much!
#
Loqi
gargron has 3 karma
#
aaronpk
sounds like only a couple things we need to verify on websub.rocks then
timbl joined the channel
#
Zakim
excuses himself; his presence no longer seems to be needed
#
Loqi
yeah who invited you anyway Zakim
#
Loqi
[cwebber] #242 sharedInbox / siteInbox type endpoint (publicInbox, but not just for public posts)
#
cwebber2
https://github.com/w3c/activitypub/issues/242#issuecomment-314880073 might be the easiest way to make this both feasible and simple too
#
Loqi
[cwebber] 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.
#
cwebber2
though, again, it won't help with blocked actors.
#
cwebber2
assuming you didn't propagate the block.
#
puckipedia
cwebber2: well, blocks only promise no interaction
#
puckipedia
anyways, imo above would basically be the server using an internal mechanism to federate activities
xmpp-social joined the channel