#social 2019-08-15
2019-08-15 UTC
# 
curiouscat Bye
# melody i was....typing
# melody grumbles about IRC's lack of affordances
# dansup heh
# melody it probably wasn't a useful answer anyway
# dansup ActivityPub and NaCl could work, still need a way to share the decryption key though
# melody i don't think AP has useful semantics for real time chat, and that's not just a presentational issue, it doesn't have the primitives for presence, rooms, or keeping the integrity of message chains, you could torture it into working, or build a lot of extensions to try to support it, but it'd be a painful retrofitting process to do well
# melody in all seriousness, i was just going to say "whichever one the person you want to talk to is already using" there's no standout options here
# melody IRC isn't private, XMPP is dying & a lot of its clients don't have support for OTR, Tox has always had questionable cryptography and the dispute with their governing foundation has left things...messy, matrix only has one client with encryption support and it has unusable UX, Signal requires disclosing phone numbers, most other options are proprietary
# melody cryptocat used to be a relatively easy recommendation for quick/small things, but then it did that implosion act
# dansup oh yeah for real time chat there are better alternatives
# melody i wouldn't want to implement a service on any of the existing chat protocols
# dansup i was thinking more like Direct Messages
# melody i see "chat" and I assume real time, maybe that's a bad assumption
# dansup nah, I'd say that is what most people would assume nowadays with slack, discord and stuff
# melody i mean i've assumed it since that phrase would have been "AIM, MSN, ICQ, Yahoo Messenger and stuff"
# melody :P
# melody regardless, i don't think anything out there right now is really well-positioned to like, take over this space in a positive way, identity servers are something of an issue for matrix adoption, mattermost/rocket chat/zulip are too siloed, IRC doesn't meet modern needs and seems ill-positioned to ever do so, Chat-Over-IMAP is an interesting experiment but I don't think it's actually a good idea
# melody activitypub could be made to work, but it'd be unrecognizable from the version of activitypub that has been deployed anywhere and not interoperable
# melody XMPP is the best option, but it suffers from aging or dying clients, a (unfortunately well-earned) poor reputation, and too much necessary functionality split into extensions such that you can't rely on clients to support critical features in a modern messaging context, and designing for the most broken common denominator drags you back to the 90s
bralyclow, bralyclow01, bralyclo_, Guest84_, xmpp-social and vitalyster joined the channel; vitalyster left the channel
# 
jaywink[m] I guess the OP left but I'd recommend taking a look at the Matrix protocol (https://matrix.org). It's an open protocol governed by the Matrix Foundation featuring lots of modern features including end2end encryption and cross-device state. It's also decentralized in the way that rooms and messages are not at whims to the location they have been created at.
Guest84, TheLie, KjetilK_ and Guest84_ joined the channel
# melody i mentioned matrix several times, it's got a lot of problems
Po-chiangChao[m] and cwebber2 joined the channel
# jaywink[m] everything has problems :) you just need to find the one where the problems are not blockers in your particular case and the things that work well are the ones that are most beneficial for you
# jaywink[m] "unusable UX" is also a bit opinionated. UX that doesn't work for someone might be great for another
cwebber2 joined the channel
# melody the riot client is a hot mess and it'd be really hard to argue otherwise, it's cluttered, there are no UI hints, and nothing does what any reasonable person would expect having used any other software ever, especially around the groups functionality which by and large is just actually broken
cwebber2 joined the channel
# trwnh if you want presence then use xmpp, is basically the answer given in response to any protocol. stateful protocols have mostly all bitten the dust due to the rise of mobile, REST, and so on >melody: i don't think AP has useful semantics for real time chat, and that's not just a presentational issue, it doesn't have the primitives for presence, rooms, or keeping the integrity of message chains
# trwnh otherwise it's "good enough" to use ap. just use "context" for the room
# trwnh everyone posting to the same context should be posting in the same room
# trwnh or topic, or thread
# trwnh or whatever metaphor
# trwnh "context" is intentionally vague
# trwnh also re >XMPP is dying & a lot of its clients don't have support for OTR
# trwnh enough clients have otr that it's still a standard for journos
# trwnh omemo is the new hotness bc it gives you perfect forward secrecy across multiple devices
# melody OTR also requires active presence, it's not really suitable for partial-async services
# melody i don't see how you would use context for rooms
# melody unless you are talking about something other than the JSON-LD context, but that's absolutely not what the JSON-LD context is for
# melody and its not really vague, it's very defined in the JSON-LD standards
# trwnh i'm not talking about the json-ld @context, i'm talking about the activitystreams "context" property
# melody anyway you can't just use context for rooms -- the situation with follow semantics makes delivery if the room isn't an actor acting as some kind of relay a complete impossibility
# melody you'd need to torture AP beyond recognition to use it for real time chat
# trwnh idk what the deal is with "real time" here
# melody at least if you want people to see the messages
# trwnh given a fast enough async the difference is irrelevant
# trwnh even "real time" isn't real time
# melody AP's semantics are not designed for making fast-enough async plausible and it has no model for reconciling conflicts across the network -- there's no guarantee of eventual consistency, just best-effort eventual delivery
# melody it's just not an appropriate protocol for near-real-time chat
# melody the context property isn't enough to deal with group or room membership & message delivery to actors that don't follow each other, so you're already living deep in weird extension territory just to get any kind of multi-user messaging to work at all other than like, multi-user DMs, which can be handled with addressing but doesn't really solve the issue
# melody for microblogging the inconsistencies largely sorta work because not being able to see an arbitrary number of messages is sorta fine if people aren't actually having a conversation and are mostly just dropping disposable replies on each other or pushing notifications around, but it's the kind of unrealiability that makes any sort of actual chat dead in the water
# melody i really like AP, it's just really not designed for or workable as a chat system -- it'd be kinda rough even for less real-time stuff, but you'd need to mangle and extend it significantly to make chat work
cwebber2 and ilmu joined the channel
# trwnh i mean yeah it's more like email and mailing lists, but "eventual consistency" can be solved by simply having one server be authoritative for the conversation
# trwnh i.e. whichever server is storing the "context"
# trwnh so you send all your messages to the server, and the server relays the messages to all participants
# trwnh yes that's not as ideal as a purpose-built protocol like xmpp, but it's good enough
# melody it's not really, you still have the delivery problem, but i'm not gonna argue about this any further
# trwnh it's not really "weird extension" either, the only broken stuff is when existing impls assume too much
# trwnh all i'm saying is that posting to a "room" is not too different than posting to a "group". if people chat over *email*, i'm fairly sure they could chat over activitypub.
# trwnh it just can't be done in a "decentralized" way because the history and delivery has to be handled by one server
# melody people don't actually chat over email, and when they do they suffer from the same kinds of consistency problems -- and groups are also not in AP and would need significant extensions to be usefully added
# trwnh for best results, that is
# trwnh what do you mean "groups are not in AP"????? Group is supported in AP, are you conflating AP with the existing implementations?
# trwnh on a fundamental level if you can GET and POST, you can do anything
# melody groups are not in the AP protocol, there was a proposed extension for "groups" but it was really just a naive relay with no access control
# trwnh everything else is built on top of that
# trwnh uhhhh
# trwnh AP is built on AS2
# trwnh just make an actor that is a Group
# trwnh you can do literally whatever you want for the logic, you just need to handle messages POSTed to your inbox
# melody Yeah that's not enough actually, it would need to be part of the C2S and S2S specs for any interop to work for any actual functionality associated with groups
# melody you can say an actor is a group but you can't actually do anything with groups functionally
# trwnh why not?
# melody all of that would need to be handled by extensions
# trwnh the members of a Group are anyone that sends a valid Join https://www.w3.org/TR/activitystreams-vocabulary/#dfn-join
# trwnh you can mandate Accept/Reject for closed groups
# trwnh and then just redeliver any activities that it receives in the inbox to members
# trwnh none of this is extension territory
# trwnh it's just unimplemented
# melody The vocabulary isn't enough though, there's mountains of undefined behavior
# melody The vocabulary may make it possible to create the extensions, but not to actually usefully interop
# trwnh you could also publish received activities to a "wall" i.e. a webpage
# trwnh you could literally do whatever you want
# trwnh i'm just confused if by "interop" you mean "work across all implementations", because that will literally never happen in any open-world system. implementations will use what they understand
# trwnh and they can ignore anything they don't understand
# melody Yes, but you can always do literally whatever you want, the point of a protocol is to _NARROW_ "whatever you want" so that people can actually interop
# trwnh at the most basic level all you need for delviery is GET, POST, inbox, outbox
# trwnh i'm really struggling to think of a meaningful area where that isn't enough to be useful
# melody delivery isn't enough for meaningful group functionality, and the vocabulary doesn't specify enough behavior to make meaningful interop with groups possible, you need to tie the vocabulary together with definitions for the actions, some things may be relatively comparatively obvious, but you need the protocol or extension to define the behavior for the things that aren't, like sure maybe accept/rejecting is good for a join to a group object
# melody like what should happen if you follow instead of join a group and are those different
# trwnh Answer: whatever the server decides
# trwnh maybe it just throws away your Follow
# trwnh or maybe it sends you any public objects it determines should be posted to the "wall"
# melody yeah, that's not a protocol, that is why people write extensions, so that people can agree on things enough to work together
# trwnh it doesn't have to be the same for all software
# melody "you can do literally anything" isn't useful, of course you can, the protocol standards exist to make sure there are some things you should or should not or can or can not do, so that iterop is possible
# trwnh well this is a major source of disagreement because "you can do literally anything" is the entire appeal / reason of being for open-world systems in general
# trwnh if you start to over-define then you're making your protocol useful for more limited niches
# trwnh but useless to those outside the niche
# trwnh like really at its core as2 puts stuff in terms of actor-activity-object, and then ap lets you make other servers aware of stuff by describing how to GET and POST to inbox/outbox
# melody the entire point of a protocol is to remove possible options, it's an effort of curation and simplification, a narrowing down of possibilities so that people aren't using incompatible schemas and types and unable to interop, closed systems with APIs already do literally anything, and you can access their data, if you write specifically for it, but a protocol exists to coordinate and narrow down the field of possibilities enough to use a shared
# melody language
# trwnh i think it might be useful to reframe the question/assumption
# trwnh rather than "how is this done?" you should be asking "can software understand this?"
# melody and it can't unless it's defined, the vocabulary leaves a lot undefined, as does activitypub, that means that you can do a lot, it also means that most software will not understand each other without extensions defining things that were previously undefined
# trwnh can you give an example of something that is undefined that should be defined? and if so, how should it be defined, in a way that doesn't preclude other implementations?
# melody mastodon is exerting a lot of influence on undefined behavior as the furry elephant in the room acting as a reference implementation, software that doesn't implement mastodon's extensions can't interop
# trwnh can't interop *with mastodon*
# trwnh if we were to judge the protocol by what mastodon does, we would be greatly limiting ourselves
# melody right, but it'd be the same with literally anything else -- anything that wants to interop with anything needs to specify its undefined behavior one way or another
# trwnh the most interesting uses of activitypub, the most useful future implementations, i feel, will not be compatible with mastodon. full stop
# trwnh at least not 100%
# melody the definition of that undefined behavior is an extension
# trwnh mastodon makes too many assumptions
# trwnh it is a status-based microblogging server
# melody mastodon has added mostly-undocumented extensions to the activitypub protocol, if we had a formal extension process i suspect some of them would have been defined by now
# trwnh anything beyond "note with attachment" is too much for it to understand
# trwnh the only things mastodon has done, have their own contexts. e.g. using the toot: namespace
# trwnh which is basically just focal points for images
# trwnh and "featured" on profiles
# melody and its implementation of signatures and its semantics for handling the different addressing combinations
# melody and federated block activities
# melody and several other things
# melody those are all protocol extensions
# trwnh i shudder to think of what would happen if those things became standard
# trwnh that would be a Bad Outcome
# trwnh but still technically they're not extensions
vitalyster joined the channel; vitalyster left the channel
# trwnh they're just undefined behavior. sending a Block is out-of-spec because Block is not supposed to be sent over S2S, but still, the meaning can be inferred
# melody i'm not saying they should be, i'm saying that in order to get actually useful behavior, you need to add protocol extensions, especially for things like groups -- group handling is entirely undefined by the spec, you may be able to guess at what other things will be doing, but once it comes time to actually interop, there will need to either be a written extension or a reference implementation that people can use if they care to interoperate
# trwnh you can do what you want with a Block activity. you can even do nothing, if you don't understand Block
# melody yeah, and that's also a bad outcome
# melody hence the need to define extensions
# trwnh it's a bad outcome only for mastodon
# melody it's a generally bad outcome actually
# trwnh the rest of the non-Mastodon activitypub-speaking network could handle blocks properly on ingress, and everything would be fine
# trwnh that's just open-world
# melody how do you know what "properly" means without a definition?
# trwnh you don't need a definition. "proper" is relative to the implementation
# melody implementations having different block semantics is a nightmare for users who rely on it as a security feature
# melody this is what i'm talking about
# melody you need defined behavior for interop
# trwnh if you receive a message from someone you have blocked, you can decide to filter it out
# trwnh that's business logic
# melody it's especially critical to define the behavior for security features
# melody blocks are not just about incoming messages
# trwnh blocks are about discarding interactions with your Objects
# trwnh so de facto yes, they are about incoming messages
# melody not as long as sharedInbox is in the spec
# trwnh if you want them to be anything more than that, you need to change the problem space from delivery to access control
# trwnh sharedInbox is a mistake
# melody i agree
# melody it's also in the spec
# trwnh the spec also says you should generally use it only for public activities
# trwnh sending followers-only posts to sharedInbox is, in effect, ceding access control entirely, and access control requires *control*.
# trwnh either you are fine with messages being handled varyingly (in which case you continue to deliver them), or you are not fine and you want to decide how they are handled (in which case you should switch to access control)
# melody i'm really sick of fighting with you about this -- a vocabulary is not sufficient for a protocol, there is some group vocabulary, but in order to get groups that can interoperate with other software, you need to add some definitions for how those groups should work, what activities can interact with them, etc -- so that other things can also interact with groups -- otherwise everyone will just do different incompatible things with groups
# trwnh it's like people are too afraid of being "centralized"
# trwnh it is valid to have one server handle things, if you wish to control behavior!
# trwnh at the end of the day, what matters is what happens with what you GET/POST with inbox/outbox
# trwnh that's really what it comes back to
# melody when i say "extension" as in "you would need to add a bunch of weird extensions to usefully use activitypub for real time chat" i mean extension both formally and informally -- you will need to define a lot of behavior that is currently undefined in implementations, and if you care about interop, you should probably write those definitions down
# trwnh i don't think it's fruitful to keep circling the conversation around this
# melody that is an extension
# melody if the behavior is formally undefined it is not useful for interop, once it gets defined (either formally or informally, by way of de-factor reference implementations) it has become a protocol extension -- AP for chat would require such extensions to be useful
# trwnh i guess another thing is that there was some misunderstanding re: the use of "extension", where you refer to extended *specifications*, but i was referring to extensions of the *protocol*.
# trwnh like, activitypub doesn't require webfinger, but mastodon does
# melody you would need to extend the C2S protocol to define how clients should interact with groups, because that's not defined, and will require side effects that are not defined
# trwnh that doesn't make webfinger part of activitypub
# trwnh anyway it's a moot point because there still aren't reference impls of a pure AP server and client
# trwnh i'd love to see that change, though
# melody no, but you could consider "how to use webfinger with activitpub" as a protocol extension that mastodon has defined by way of being a reference implementation, there are certain actions you need to take w/r/t dereferencing webfinger
# melody in order to interop
# melody those side effects as they fit into AP are a protocol extension
# melody an optional one but not optional if you want to interop
# trwnh not optional if you want to interop with *mastodon*
# melody not optional if you want to interop with other implementations that require webfinger
# melody the point is that makes it an extension of the protocol
# melody the semantics behind a lot of things that are undefined end up being security-critical infrastructure, without formal definitions, that's a problem
# melody so to drag this mess back -- if you wanted to build any sort of secure, near-real-time chat over AP you would need to define a lot of undefined behavior in a way that is reproducible and at least somewhat formalized, and I don't think it makes sense to try to do that, because some of the things that *are* already defined don't really fit that use case well
# trwnh disagree with >some of the things that *are* already defined
# melody i like AP mostly, but we shouldn't lie about what it's a fit for
# trwnh it's best for email-like use cases, and linked data webs
# trwnh bc that's what it was designed for
# trwnh that doesn't make it unable to do more communication-based things
# trwnh since it's actor system
# trwnh the "somewhat formalized" way right now is jsonld @context
# trwnh and of course the docs of individual impls
# trwnh but in the larger picture it doesn't make sense to limit oneself to interop with everyone
# melody that defines the vocabulary, not the side effect behavior
# melody you need to define extensions if you have side effects that need to be replicated for interop
# trwnh only assuming the side effects need to be the same everywhere
# trwnh if the side effects are only happening on one server then that's fine
# trwnh like let's say you could comment on a website by emailing a particular address
# trwnh does it *really* matter what the website is doing? it could append your text body to a web page, or it could send it to an application for review/moderation, or any number of things
# trwnh all that matters to you is that you were able to send the text body over email and you didn't need to sign up for an account on that website
# melody it can be important for the side effects to be the same everywhere, there are usually UX implications if nothing else
# melody maybe not for your weirdly contrived use case
# trwnh the only ux implication is if you care at all about sync
# melody you typically care about chats being in sync
# melody which was the entire fucking point of this entire hole you dragged me down
# melody for fucks sake
# trwnh you don't really care about chats being in sync if you've only got one authoritative server though!
# trwnh that's the whole point of having one authoritative server
# trwnh it's authoritative
# melody yeah that's not necessarily a great assumption if you want decentralization, which again, is part of the point here
# trwnh ok so i don't care about having a globally synchronized database of messages at all
# melody good for you, that's a pretty common need for a chat system
# melody which is one of the reasons why i said AP isn't super fantastic for that
# trwnh i care about interop, i.e., i want to send messages without signing up for a million different protocols, all we're doing here is passing around text and maybe some attachments and metadata, how hard could that possibly be
# trwnh so if i can POST to an inbox then that's really all i care about
# trwnh and if i can GET whatever the server has determined is relevant, then that's all i need
# trwnh otherwise i'd keep using irc
# melody it's actually hard if you care about security or harassment or spam or actually successfully communicating
# trwnh i defer to whatever software would be hosting the communications
# trwnh i mean like... if you want a globally synced database then use Matrix
# trwnh theoretically anyway
# melody matrix has other issues
# trwnh but matrix is actually designed for that (nominally0
# melody which is why i said...don't use AP for this
# melody like, AP is a poor fit for chat systems was my entire point
# trwnh AP is "good enough", despite any/all of its shortcomings
# trwnh even email is fine
# melody and then you've been arguing with me about that because like technically you could do it if you sacrificed allt he functionality of a chat system
# trwnh a lot of orgs/projects still use smtp mailing lists
# melody other things that don't really work well in the existing spec re: chat systems, are like, any & all of the semantics associated witih follow/following and delivery to followers since that's not how chat works
# melody i'm not sure why you keep throwing out things that work very poorly as if they are counterarguments
# trwnh my point is that they work
# trwnh and apparently nothing better has come up yet
# trwnh because we keep getting new protocols that reinvent the wheel
# trwnh even AP is basically just email as far as S2S is concerned
# trwnh XMPP could replace everything including HTTP but it hasn't
# melody you're just babbling now, i'm out, this has been exhausting, thanks
# trwnh when over a billion people use facebook
# trwnh i really think it's not productive to start looking at overspecifying the details. if it works it worrks
# trwnh like, heck, we could still be using SMTP for everything if we were concerned with extending it
# melody the details matter, and thinking they don't is the repeated overwhelming flaw of nerd junk
# trwnh details matter but they don't have to matter to everyone. scope is a thing
# trwnh either way i'm all for ending the conversation if you want, since we clearly disagree on fundamentals
# trwnh to me having one server manage a conversation is fine
# trwnh to you it's sacrificing decentralization