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?
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
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
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
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: 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
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
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: 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
tantekI'd expect independent implementations to experiment with new properties before they're even publicly discussed, much less added to a centralized context
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
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
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
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: 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
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
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
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
tantekI see it as pretty important that we continue being able to evolve vocabularies even after widespread federated heterogenous deployment of protocol implementations
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?)
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.
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
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.
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
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
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
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.
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.
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."