#xmpp-social[Takyoji] Just for clarification: is ActivityPub essentially acting as a neutral transport for the 'Objects', or is there any specific behavior that should occur if the server doesn't understand the type of Object being received (such if it's something other than the ActivityStreams types)?
#xmpp-social[h2b] ajordan, I got a problem with my jabber account password change. A few hours ago, my laptop with all digital data was stolen. The system automatically authorizes in the account on operating system startup. I forgot my password and cannot restore the access. Please help me
xmpp-social, timbl, Gargron, JanKusanagi and jankusanagi_ joined the channel
#cwebber2cwebber2: we don't have enough time it seems to be able to cancel, so I'd prefer to either reinstate meetings or switch to 90 minutes meetings
#cwebber2tantek: probably easier to do 90 min meetings, sandro said they may think that's what happens during times like this in other groups?
#Loqi[tantek] #25 Response Type: move "reply" to 2nd to last to enable p-summary fallback use-cases
#cwebber2tantek: one thing I wanted to go over was issue 25, eg how to handle replies and fallback, it talks about extensibility a bit, which is adding new features over time which we've done in general for PTD. So specifically for responses, any kind of response like likes, posts, shares, we almost always have text equivalent which is something we've seen when people post things to twitter, or facebook has an "all activity" page where you can
#cwebber2tantek: that being the case, if some new response type comes up in the future, like you're bookmarking something or etc then you should always be able to say "hey this is a response" and then have text equivalent in summary property
#cwebber2tantek: so any existing impls that don't know as response will be able to show something sensible, as in something author produced that shows something sensible
#cwebber2tantek: I wanted to get feedback/observations on whether they agree/disagree, etc
#cwebber2sandro: tantek, are you looking for general feedback or a vote?
#cwebber2tantek: I feel pretty confident about this change so I wanted to bring to the group explicitly. other than objections and people saying "no you're wrong this will never work", I would like feedback on "this sounds reasonable", but I can accept lack of feedback. Ideally I'd like to say "accept my proposal and publish a new WD based on this change". that's my longest answer to you
#cwebber2sandro: anyone have any feedback? seems like that's your quiet answer for now
#cwebber2tantek: that's ok, figured this would be a group for feedback, but if people are fine I suggest we publish a new WD with this change
#cwebber2tantek: I think that's a reasonable request to make?
#rhiaro... since I'm uisng a cool new bleeding edge non blocking async implementation, something isn't implemented yet, and I have to add something to the language
#rhiaro... Looking at the screenshot, you have a number of 'OK's - are they not meaningful because of the async problem or is this something someone could run now?
#rhiarocwebber2: the next one is about the Accept/Reject stuff
#rhiaro... talked to evan last week about it.. then did some more reasearch
#rhiaro... Some servers think about Follow as 'hey I want to subscribe to your public updates'
#rhiaro... in AP you can address to Public and/or followers, but not necessarily both
#rhiaro... This is how twitter and mastodon have this concept
#rhiaro... in Mastodon you might follow someone. Usually the follow is just automatic, but if they have a private account, they manually accept and reject who they're following
#rhiaro... when they send stuff to followers that stuff is not public, it only goes to the followers collection
#rhiaro... they're using it as like a trusted friends collection
#rhiaro... at the end of last meeting, evan suggested we can still use the followers thing for the public subscribe, and pointed out that AS2 has a way of doing this kind of subscription using Offer and Accept/Reject on offer to do friend requests
#rhiaro... I took a look and thought about it and unfortunately I think that's going to result in something disjoint, because we'll have two different mechanisms for follow
#rhiaro... you still might send a Follow request to somebody and yu would effectivley be a diferent system
#rhiaro... AJ raised a concern that maybe we won't get this specified in time
#rhiaroeprodrom: These are two very different ways that different social networks do the social graph
#rhiaro... The fact there are two different ways to do it is already out of the barn
#Loqi[cwebber] Amy suggested over PM that:
* If a server returns 200 or 201, assume the follow just went through
* If returning 501, the server doesn't support following
* If a server returns 202, then the server will send an Accept / Reject
#rhiaro... This does introduce another state which maybe is why evan is -1ing it
#rhiaroeprodrom: We just tend to represent this kind of thing as activities not http replies
#rhiaro... if you have different types of social graph behaviours we tend to represent them explicitly as json structures
#tantekquietly thumbs-up the questions/comments he agrees with
#rhiaro... Cant' we have two different mechanisms?
#rhiarocwebber2: if we implemented two different kinds..
#rhiaro... a) if we add the Offer and relationship thing we're going ot have to add that like immediately and I'd need your help because I don't think I'd get it completely right
#rhiaro... THe other side of it is I"m not sure the Accept/Reject, aside from backwards incompatability, is so bad, because if you look at the case Mastodon supports both
#rhiaro... automatic public accounts, and private accounts
#rhiaro... The implementation just automatically returns an accept if it's a public account
#rhiaroeprodrom: Right. Alice wants to follow Bob, Alice sends a Follow to Bob and at that point the request is that their relationship is in a waiting state
#rhiaro... then Alice should receive either an ACcept or Reject
#rhiaro... While it's in the waiting state, Alice should not show up in Bob's list of followers, Bob should not show up in Alice's followees
#rhiaro... Maybe there's a third stream of like open invitations that are in waiting
#eprodrom"For example, Undo may be used to undo a previous Like or Follow." -> "For example, Undo may be used to undo a previous Like, Follow or Block."
#rhiaro... I'm moderately convinced actually that the spec text does a good job, and we can move on if everyone else is okay?
#rhiaro... We could add a blocks property to actors and say hey it should be in this collection. Useful for client to server, but suepr weird because only the actor would be able to read that collection. So it would be weird to notice that on a person's profile
#rhiaro... Seems strange, but would be okay with adding it
#tantekFlickr and Twitter both provide a viewable blocklist. Twitter provides API for reading it too.
#cwebber2tantek: not on JF2 but on websub, I want to know what's next step on websub?
#cwebber2aaronpk: good question, I think we have enough implementation reports to have one of each role
#cwebber2sandro: last time we talked about this I think I said we also need implementation reports to major existing implementations? mastodon for example
#cwebber2tantek: we believe websub reports exist, are waiting for reports?
#cwebber2sandro: I don't think we should wait that long if we don't have to, would be good to have wrapped up in september
#cwebber2sandro: unless we have a real reason to wait
#cwebber2eprodrom btw the reason you saw so many passing in the screenshot was because it was running against my implementation, testing against puck's found some more issues that need to be resolved on theirs, mistakes I had made also but had fixed in my implmentation
#tantekalso wonders if there are any open issues on Webmention
#cwebber2aaronpk: now that we're in Rec, if people find minor typos or larger possible issues (not adding features) what options might there be for normative issues?
#cwebber2sandro: my understanding is that in the link you may point to errata, which could point to issues
#cwebber2aaronpk: what's the process of going from issue -> errata?
#cwebber2sandro: if there seems to be no disagreement, copy it over
#cwebber2sandro: more like traditional FOSS'y stuff, just assume everyone speaks for themselves and nobody has authority over anyone else, just document if nobody disagrees, if disagreement then document that too
#cwebber2aaronpk: makes sense but looser than I expected
#cwebber2sandro: I've never handled a case where errata happens during WG
#cwebber2aaronpk: there is an issue but I wanted to understand what to do in general since we have a running WG
#cwebber2eprodrom: could I pose a suggestion, which is anything you don't feel comfortable unilaterally updating might not be an eratta? may be something normative or which needs to go into next version of spec?
#cwebber2tantek: may be a bit too much burden to put on an editor, because it's a REC we have more bearing on what we need to do
#cwebber2tantek: we resolve it on how we resolve any other issue
#cwebber2tantek: since we have a link in the doc which links to an errata document, a WG resolution on an issue drives addition of stuff to that page. becomes a delta document of sorts
#cwebber2tantek: if we get to the point saying this is a non-trivial amount of errata, there's a process for releasing 1.01 or etc. depends on if it's normative or non-normative changes
#cwebber2tantek: we can cross those issues when we get there
#Loqi[voxpelli] #101 Should string really be a MUST for non-HTML content?
#cwebber2aaronpk: I'm on board with typo issues just filing them without discussing them, but this one is technically normative but spirit of this was incorrectly converted into text for the spec
#cwebber2aaronpk: the content property MUST either be an html object or a string
#cwebber2aaronpk: intent was by default it's text, if html it's html text which allows for ability to do extensions in future we haven't thought of now
#cwebber2aaronpk: way we have it now it's not technically possible to do extensions
#cwebber2aaronpk: this would be normative, but would allow extensions to happen.
#cwebber2aaronpk: it's extensibility, not a feature itself
#cwebber2aaronpk: it's the ability to add features itself, not going to make it so you have to do things differently with current implementation to support features as-described in spec
#cwebber2tantek: that depends, what text do you have in terms of what to do when things aren't recognized?
#cwebber2tantek: does the spec say what to do if there are additional keys or not in content property?
#cwebber2tantek: if that's not explicit, there's work to do to research on right behavior and etc
#cwebber2tantek: are we documenting mutual agreement or disagreement?
#cwebber2tantek: that makes it basically a feature
#cwebber2tantek: feature is for compatibility, essentially
#cwebber2tantek: in that case you allow langugage that does
#cwebber2tantek: that allows for extensions to happen , etc
#cwebber2tantek: not a user-facing feature, but it allows interop
#cwebber2sandro: can be filed as a recognized problem, but we can't say here is the approved solution... we can only take a solution as far as what would be a working draft, but we can't have w3c recognition on approved solution
#cwebber2tantek: if we believe resolution is what's approved we can take it to CR directly without WD
#cwebber2sandro: in theory, I'm not sure that's part of approved use of time
#cwebber2tantek: if it's a non-breaking change, maybe can move to PR directly
#cwebber2sandro: before anything goes to AC, I need to see if it's in-scope for extension which is debatable
#cwebber2tantek: it's open for interpretation, but IMO maintenance is something any charter extension would/should support
#cwebber2tantek: but before we try to answser the hard problem, if there are any typos or etc that you can resolve by proposing errata text to add to the doc etc and add to them, that would be a good start
#cwebber2tantek: maybe cherry pick an easy one for the next telcon, try to reduce set of open issues down to harder ones
#cwebber2tantek: can try to figure out least-impact path forward for those
#cwebber2tantek: similar to micropub we have open webmention issues that are probably worth processing into webmention errata, so aaronpk maybe see if you can quickly document into errata etc
#cwebber2tantek: vs request for new feature too, you can document separately, point is to process open issues
#Loqi[evanp] @strugee I don't know. I think that mechanism is a bad idea. I think the best you can do is do the brittle method, with possibly doing some type inferencing in JSON otherwise.
#ajordan"Object wrapped in Create" rears its head again
#ajordanI believe it was puckipedia who wanted an answer to this question?
#ajordan(the question being "how to determine whether an arbitrary object is a subclass of Activity?")
#ajordanI don't remember why that was added and I know cwebber2 likes it but tbh wrapping things in a Create clientside just doesn't seem like that much effort
#Loqi[cwebber] I've become over time a lot less of a fan of the "auto-wrap-in Create" feature, though I'm even *more* not a fan of requiring a Create at all... I think just-an-object could be the same as wrapping in Create, and the Create is indeed fairly artificia...
#cwebber2puckipedia: you can't handle extensions' side effects that you don't know about anyway
#cwebber2so them not being interpreted as Activities doesn't matter much
#puckipediaso now extensions are randomly wrapped in Create
#puckipediaI'd say require Create, and if a server can't process a specific activity just have it error
#cwebber2puckipedia: I don't think you should be accepting types in C2S that you don't know about
#puckipediawhich is making the {Create} implicit, /buuuut/ can also be represented explicitly
#puckipediawhich means that Mastodon/GNU Social don't differentiate between the implicit Create and the object
#cwebber2uhoh, that was exactly what I was going to suggest ;)
#puckipediawell, didn't you suggest just scrapping Create altogether?
#puckipediaI mean, if you want, you can implicitly use a Create in OStatus. but Mastodon won't read it because it isn't implicit
#puckipediabut yeah. I'd be OK with removing the Create if that's the average consensus. I would have more issues if it were possible to use it, but not required
#saranixFor me, I felt like the Create actually solved a lot of things
#tantekas informally mentioned on the telecon this morning (audio) before we started officially, here's my summary and scene by scene listings of the features demonstrated in the The Social Network trailer, as material for a social web test where the different roles are performed by people with different services/sites/implementations: https://indieweb.org/The_Social_Network#Trailer
#saranixa quote from hubzillaland "Protocols design is like this: if the protocol designer only can think of saying A, then all you will get to say is A. This is fine if all you want to say is A. If you can think of more to say than A, something clever, like B, but you are only allowed to say A, you will become unhappy fairly quickly. This is not the problem, the problem is the millions of people who believe getting to say A is really amazing."