#Gargroncwebber2: should i redownload the AS context?
timbl joined the channel
#cwebber2Gargron: not yet, the vocab isn't out and neither is the updated CR. should be within the week
xmpp-social, KjetilK__, KjetilK and KjetilK_ joined the channel
#Gargronyo, d'y'all think I can send a Delete->Actor activity when someone deletes an account (or an account is suspended) to save on sending delete activities for every single thing they created?
KjetilK_ and timbl joined the channel
#jaywinkThis is how AFAICR diaspora works -> just one AccountDeletion entity sent out and recipient servers are excepted to deal with that information. For example Hubzilla (afaicr) instead sends out a delete for each activity, which can result in thousands of payloads where some older account is deleted. IMHO it is logical that servers handle an Actor delete in a way that they process a delete for any stored
#jaywinkbut I don't think it sends a delete. it's a proper move afaict
#cwebber2pump.io, people run a script that deletes all their posts and adds them to another instance
#jaywinkdiaspora migration is also a proper migration, protocol support landed a few weeks ago
#cwebber2jaywink: yes I'm saying that the issue I'm talking about is when people use this *instead* of a proper move, because the system doesn't suppor tone
#cwebber2which IME is the most frequent usage of deleting an account and all posts *currently* (due to limitations)
#jaywinkDelete -> Actor with a "really, u sure?" boolean ;)
#cwebber2I guess rm -rf ~actor would be more appropriate ;)
#jaywinktbh, Delete logic shouldn't be working somehow because another feature is missing and people are "abusing" it. for me, receiving a Delete would mean "purge all the content this user had". well, unless the spec has some other opinion :D
#cwebber2jaywink: yeah I guess I'm not talking about from a spec level here
#cwebber2I'm kind of grumbling about an in-practice issue
#tsyesikacwebber2: Another thing we discussed, we need aaronpk to come to a conclusion is discussing extensions
#tsyesikacwebber2: the first one is the "sensitive" property - various systems have in place some kind of boolean for NSFW content, mastodon has it and is doing a major roll out of AcitvityPub
#tsyesikacwebber2: the other extension is the tag type
#tsyesikacwebber2: we spoke to json snell asking why and he said there probably was one but he doesn't recall and (why not have it?)
#tsyesikacwebber2: tantek yes they're the same, when it was initially written up it was called "tag" but evan thought it was clearer as hashtag and that's also what Gargron implemented
#tsyesikacwebber2: those places on the wiki should be updated to "hashtag"
#tsyesikacwebber2: I fleshed out the wikipages, linked above
#tantekseems fine to me - bikeshedding I can't care enough about :) - I know we don't care as much about silo prior art here - but FWIW FB calls it "tag" everywhere. E.g. tag someone in a post, tag a location etc.
#Gargrontantek: ActivityPub has "tag" property which, like you say, is an array of mentions, categories, locations, whatever. But FB also has "hashtags"
#tsyesikacwebber2: those are the two suggested extensions. Part of the challenge is we don't have a process yet, the CG does have authority to ? extensions but we shouldn't go willy nilly with this
#tsyesikacwebber2: mastodon is using linked data signatures
#tsyesikaGargron: to use linked data signatures, you're required to cononicalize the json. It converts the property names from the short from e.g. "tag" to it's fully qualified name based on what is included in the context
#tsyesikaGargron: to verify signatures you need to download the context so basically you either need to DDOS the single context server or cache it
#tantekI think we agreed to only adding to the context document IIRC. Or was it AS2 vocab that we agreed to only grow?
#tsyesikaGargron: the problem with the context changing is the signatures will change if the context changes
#tantekwow Sandro sounds so much better on Mumble than on Webex. so much more human
#tsyesikasandro: we only add terms to the context, (terms may be deprecated but they'll still exist)
#tsyesikasandro: this would be a problem when someone uses the new term and sends it to someone who hasn't picked up the new term
#tsyesikaGargron: the problem is that it'll invalidate the signature
#tsyesikasandro: systems ought to if there is an invalid context - they should reload the context
#tantek"how is this supposed to work for anybody ever" is kind of my summary thoughts on signatures, but I figure smarter people are figuring it out :)
#tsyesikacwebber2: I've got one suggestion: it might mitigate the issue (paste coming on IRC)
#tsyesikacwebber2: you could have a transitional version when a new property is added to inform older versions of the software
#tsyesikacwebber2: if you look at the context put in IRC it also specifies that the sensitive property is under the AS context
#tsyesikacwebber2: then when you're 3 versions ahead you can drop it
#tantekwas quoting what he heard sandro say on the call
#tsyesikasandro: I think the right thing to do is to cache the context for around 6 hours (good enough to avoid DDOS problem)
#tsyesikasandro: if it started to become a problem w3c could change the cache header
#tsyesikaGargron: the problem isn't just the DDOS of the server, the problem is the context is only on one server and it's crucial for signatures.
#tsyesikaGargron: it's a central point of failure. caching for 6 hours is a solution but it's not perfect
#tsyesikaGargron: maybe we're over thinking the problem. the one rule of thumb which may help - never use properties which are not yet included in the context. If we never remove properties which are deprecated and we use new properties
#tsyesikasandro: a practical solution is we'll add the terms weeks before it'll be expected to be used
#tantekI'd expect independent implementations to experiment with new properties before they're even publicly discussed, much less added to a centralized context
#tsyesikaGargron: e.g. right now - I have to wait for chris to release the new context with the sensitive tag, etc. before i can release mastodon
#tsyesikaGargron: if we can make an assumption about parsing and dumping of JSON. We could just do a JSON dump to a string and sign that and we'd not have to do key sorting
#tsyesikacwebber2: you would have to do key sorting, if took the JSON into my site and my hashmap re-ordered the keys
#tsyesikaGargron: you could take the json payload and encode it as base64 and send it like that but it makes troubleshooting annoying and it doesn't give you security
#tsyesikasandro: we could add things which are experimental e.g. it goes away after 6 months
#tantekI wouldn't expect any "temporary" add to actually be temporary in practice. As soon as even one implementation depends on it across servers, you're kinda stuck with it.
#tsyesikasandro: the IETF has a bunch of media types (and other registries) it has a high bar on what should add. you could add things but it took years
#tsyesikasandro: then they added a lower bar where there is a short window where there is discussion and someone has to have a principal objection or it gets added
#tsyesikasandro: I much prefer that way so we don't have people blocking things
#tantekhas also heard of past frustrations with IETF registries of various sorts
#tantek+1 to Gargron standard follows real life implementations
#tsyesikaGargron: I have no experience with formal standards. I feel though that standards should follow real life applications - It seems more natural. In the theoretical environment you probably won't forsee all (?)
#cwebber2sandro: I think there's a distinction between allocating the name and specifying exactly what it is
#cwebber2sandro: we can allocate sharedInbox2 for someone to play around with for a while, and it may not be clear what it means, but we can eventually converge on what it means
#cwebber2sandro: name allocation is what I suggest we do easily
#cwebber2sandro: you could do that through the standards process, but we don't have to in extension/name allocation
#cwebber2Gargron: in a way I question whether the protocol needs much further development, and whether it is even very possible. the devs of signal didn't do it in a federated way because they didn't see a way to keep extending it when centralized. if we do a federated protocol with AP we have to deal with some release date and not have much change. for example I don't think there's much protocol dev with SMTP and IMAP
#cwebber2sandro: I absolutely understand; to oversimplify it I think there's an experimental or dev stage, and someone says "I'm going to play with this, do all the changes, and people should change my lead" and then at some point when they're done it's frozen, which is comperable with going to rec in w3c standard
#cwebber2Gargron: if we're Mastodon and with AP stuff and it changes, there still may be some older versions around. if we can't solve the accountability problem between versions and signatures that's how it's going to be
#cwebber2Gargron: that's the main problem with keeping federated protocols changing
#cwebber2sandro: I don't see much advantage to that, if you have two people picking the same term there may be collision
#cwebber2sandro: if Mastodon wants to play with sensitive, Gargron can play with it until defined
#cwebber2sandro: we may need to do this hack you're describing with signatures but I don't see how its useful otherwise
#cwebber2cwebber: what about use the wiki and the hack I described
#cwebber2sandro: w3c hasn't decided what the action process is, working on it, but if not an issue I don't see the advantage over not adding to the vocab
#xmpp-social[ajordan] Knowing nothing about LDS, can't you create signatures which drop e.g. properties prefixed with mastodon_?
#cwebber2cwebber: one advantage would be to not grow vocab with things you don't need
#cwebber2sandro: is there any reason not to add sensitive and Hashtag to context?
#sandrocwebber2: I think they're happening, and seem like clear sells,
#jaywinkdiaspora protocol has a way to keep signatures validating even if someone adds new properties btw, not sure if that would be interesting to compare to
#xmpp-social[ajordan] To clarify what I said earlier, could you have a system that signed all the properties in a particular context? So Mastodon would generate two signatures, one for the AS2 context and one for its experimental context
#tantekhuh - this concern about "updating the protocol" makes it sounds like the separation of protocol vs vocabulary is not working in practice
#xmpp-social[ajordan] Other implementations would drop anything not in the Mastodon context and verify the AS2 context signature
#tantekthat was a key point of separating the vocabulary, so we could more easily keep evolving it while the protocol itself stayed (fairly) static
#tantekI see it as pretty important that we continue being able to evolve vocabularies even after widespread federated heterogenous deployment of protocol implementations
#xmpp-social[ajordan] tantek: who are you responding to?
#tanteke.g. someone deciding to post a new "donation drive" post type, to which others respond to with a new "donation" post type
#tantek(not theoretical, FB has this, and there's been some #indieweb discussion about how would we do this)
#cwebber2Gargron: <bad transcription> we had bad experiences with tagging for sensitive type things, there was a nsfw type category, but if you use the #nsfw tag it's exactly the same as the boolean... this means that comes from the text or the category
#cwebber2Gargron: I gave my ok on these. I have gotten some bad feedback from NSFW so maybe exclude the mention of nsfw because it may have some problems. maybe say that it MAY apply to both text and images or just images (media?)
#cwebber2Gargron: the point is that the content doesn't need to be displayed right away is the only core element of this property
#tantekdoes it mean the author has marked the content as sensitive? the provider/server? or other users?
#sandrocwebber2: I understand the controversay for NSFW, and agree, but I think some people wont find this unless it's mentioned there.
#Gargrontantek: it doesn't carry that sorta information. only how, not why.
#Gargronfor a reader - no. admins can enforce it however.
#tantekI agree with Gargron of dropping "NSFW" from the sensitive description
#tantekwould you consider adding "trigger warning" to the "due to ... " list?
#tantekI feel like I've seen that used enough in practice that it's worthy of mentioning
#tantekand shows sensitivity (so to speak) to that use-case
#cwebber2cwebber2: tantek: what I said on the call is I agree with not having it be the name, I added it because NSFW is so common someone might not know they should use sensitive instead and invent a nsfw tab
#Gargroni believe that being so specific is not necessary. with a bit of abstraction, "summary" can be the trigger warning/spoiler warning/actual summary of the content
#sandroMaybe a solution is to have the documentation for Sensitive Property link (and from) some online discussion forum where NSFW, TriggerWarning, ContentWarning, etc, are all discussed.
#tantekcwebber2: I think I understand your reasoning for mentioning NSFW. Maybe we can dilute the effect by listing "Trigger warning:" along with it?
#tantekah I see sandro was thinking similarly already
#sandroWhich tantek requires we do via a centralized system since he rejects email archives, but so be it. :-P
#tanteksandro they're missing the social features because none of those projects can figure out decentralizes social on their own without just being yet another monoculture
#tantekwe're supposedly here to solve that problem
#cwebber2Gargron: GitHub is pretty bad IMO when it comes to centralizing what has a nice decentralized underpinning (git)
#sandrotantek, the weakness I find with that model is that most folks aren't even that motivated to express themselves in a stable way. they might make a site, then lose interest and let the domain lapse, etc.
#jaywinkI would move from github the same day someone makes gitlab federate
#cwebber2also sucks that you can't use it without proprietary js and that you get locked-in to issues, etc
#sandrookay, let's make gitlab federate. what's it written in. :-)
#cwebber2jaywink: re: gitlab + AP, there's an issue open for it
#tanteksandro, agreed, I have seen that too. yet that's the glass is half empty view. for every one that loses interest, there is a growing # that iterate and improve their site
#sandrotantek, I tend to think the solution is something where as long as any one person in (or aware of) an interaction cares, the interaction stays around. That's hard to do over DNS, but maybe with some kind of system of mirror-URLs.
#tanteksandro - pretty sure the indieweb implementations of posts and responses does that - posts keep copies of responses, and responses keep reply-contexts of the posts they are in reply to
#tanteknot quite "mirror urls", but the content is essentially copied by each side of a federated interaction
#tantekso that if either side goes down, the conversation remains
#tantekthese "copies" aren't required per se, but rather, emergent best practices
#sandro*nodnod* I'd like it so when I +1 a photo, I'm also keeping a copy of it, probably.
#tantekcwebber2: better. the phrase " in some other systems" still strikes me as odd, as I see this as cultural (per person) differences, rather than any kind of systemic / architectural difference
#sandrocwebber2, how about s/equivalent/similar/ or /comparable/ ? "equivalent" seems to give those other phrases more respect.
#sandroHow is the user supposed to know whether to when they choose to display they're going to see a slightly political joke or something deeply scarring?
#cwebber2sandro: it's different from CW but that's kind of because Mastodon (ab?)uses the summary field for CW. It's been argued that maybe sensitive + summary should equal CW but iirc nobody reached consesnsus on that
#tantekcwebber2 just don't tie it to a phone number
#sandroBut slowly coming to the point: I think terms ought to be documented in a way that allows people to use them. We don't need that on day 1, but since we're talking about the wording now, now might be a good time to add it.
#sandroHow's this: In current practice, the "summary" property should contain a non-sensitive human-readable description of the sensitive content, allowing end-users to decide whether to view it.
#sandrowithout that, it's totally unusable. (of course, people will just go look at what Mastodon does, I guess.)
#tantekor we should look at what Mastodon does and write that up as spec text
#sandrothat's what I tried to just do, albeit from asking Chris, instead of actually looking it up
#sandroMaybe I should tag @Gargron ... Eugen, is this accurate: In current practice, the "summary" property should contain a non-sensitive human-readable description of the sensitive content, allowing end-users to decide whether to view it.
timbl joined the channel
#cwebber2sandro: Gargron: wait a minute, why don't we just add an extension for "contentWarning" that works exactly as Mastodon is using it?
#cwebber2in OStatus Mastodon kind of shunted it into the vocabulary they had but
#cwebber2there's no better time to actually add the term that means specifically how Mastodon is using it than now
#sandroI see... "When hiding images, you usually mention in the toot text why you do that. That becomes the colloquial "content warning". I do not believe that the toot text needs to be hidden as well, behind a second level of click-through, for that use case."
#sandroSo it's NOT the "summary" property that tells you whether to reveal the image, it's the "content" property.