[Summit] day 1 notes

Kurt Conrad conrad at SagebrushGroup.com
Sat Oct 10 22:46:28 UTC 2015


At 2015-10-09 19:19, you wrote:
>Backing these up by posting to the mailing list. :-)

All,

Here's version formatted for improved readability (assuming the file 
comes through).

/s/ kwc 2015.10.10 15:46

___________________________________________________________________
Kurt Conrad                        mailto:conrad at SagebrushGroup.com
                                              www.SagebrushGroup.com
-------------- next part --------------
<!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Summit Day 1 Notes</title>
    <style type="text/css">
      td{
        border-top:1px solid #aaaaaa;
        vertical-align:top;
      }</style>
  </head>
  <body>
    <div>
        <h3>To: XMPP Summit <summit at xmpp.org></h3>
        <h3>Subject: [Summit] day 1 notes </h3>
      <p>Backing these up by posting to the mailing list. :-)</p>
      <p>###</p>
      <p>This pad is for notes and discussion about XMPP Summit 18, especially MUC2.</p>
      <p>Topics:</p>
      <ul>
        <li>MUC2</li>
        <li>MAM & Carbons</li>
        <li>Push</li>
        <li>Unread Markers</li>
        <li>Work through open issues at https://github.com/xsf/xeps</li>
      </ul>
      <p>MUC2</p>
      <p>Kev will provide an overview of what we're trying to achieve here. :-)</p>
      <p>Pubsub/PEP Subscriptions</p>
      <div>
        <h4>Minutes:</h4>
        <table>
          <tbody>
            <tr>
              <td rowspan="7">Kev:</td>
              <td>a long we've people have said we should ditch MUC, and we've laughed at them. for good reasons, but this year we've changed our minds</td>
            </tr>
            <tr>
              <td>a lot of people have designed their own MUC systems because MUC didn't do what they needed</td>
            </tr>
            <tr>
              <td>like MUC where presence is not tied to occupancy</td>
            </tr>
            <tr>
              <td>nick sharing is basically broken in MUC 1, based on hacks</td>
            </tr>
            <tr>
              <td>presence-less mucs, messages only</td>
            </tr>
            <tr>
              <td>doesn't play nicely with MAM (storing lots of copies, one for each client in the muc)</td>
            </tr>
            <tr>
              <td>MUC2 uses pubsub</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>What other problems? ghost users? iq requests?</td>
            </tr>
            <tr>
              <td rowspan="5">Kev:</td>
              <td>Have spent the day writing the MUC2 spec</td>
            </tr>
            <tr>
              <td>MUC2 we decouple nicks from all addressing - can see all clients behind a nick and address them</td>
            </tr>
            <tr>
              <td>in a non-anonymous room there are no fake JIDs at all</td>
            </tr>
            <tr>
              <td>in semi-anonymous rooms there still need to be fake JIDs, but not tied to nicks</td>
            </tr>
            <tr>
              <td>ghosts if you no longer tie occupancy to a room to online status, ghosts kind of go away. problem is down to stale presence</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>i think ghosts *are* stale presence</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>in muc1 ghosts are worse than stale presence, because occupancy is based on presence</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>from the user's point of view, it seems to be the exact same problem. trying to talk to someon thats not there</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>But messages will still end up arriving to the right person</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>Maybe, but the problem is still there</td>
            </tr>
            <tr>
              <td rowspan="12">Kev:</td>
              <td>Its the same as what happens with contacts in your roster</td>
            </tr>
            <tr>
              <td>If we're going to solve that one, we'll need to solve it outside of MUC2 itself</td>
            </tr>
            <tr>
              <td>Basic premise of MUC2 is that it is like PEP, similar scheme</td>
            </tr>
            <tr>
              <td>every room is a PubSub service</td>
            </tr>
            <tr>
              <td>each type of data has a node on that service</td>
            </tr>
            <tr>
              <td>anything you can put in a node, you do. to avoid any extra protocols. same flexibility for everything</td>
            </tr>
            <tr>
              <td>tie MAM into MUC2 by doing everything by using MAM</td>
            </tr>
            <tr>
              <td>can do MAM with pubsub nodes, so MUC2 gets lots of history/syncing for free via MAM</td>
            </tr>
            <tr>
              <td>fast resync happens via MAM</td>
            </tr>
            <tr>
              <td>can sync only nodes you are interested in</td>
            </tr>
            <tr>
              <td>no longer need for the history hacks in MUC1</td>
            </tr>
            <tr>
              <td>written up at: <a href="http://hector.doomsong.co.uk/scratch/muc2/muc2.html"
                  >http://hector.doomsong.co.uk/scratch/muc2/muc2.html</a></td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>to the requirements, i would add something about data types, such as files or video streams</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>a point about MUC2 is that it makes no attempts to be backwards to MUC1. It might now be sensible to MUCs in your roster now</td>
            </tr>
            <tr>
              <td>Sam:</td>
              <td>what are peoples thought about not doing an anonymous MUC but handle that via things like SASL anonymous</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>there are still cases where you want to not reveal how ?to? join a room, semi-anonymous rooms</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>two cases - people still prefer to join rooms that are semi-anon as people prefer to be very seelctive about revealing their identity; also the military case which is where the nicknames within a chat room represent active roles rather than actual people - take for example a cmdr may go into a room as the commander and how a shift change happens is that they physically take the seat (the role) of the cmdr and just assume control of the JID that is already active. In MUC1 that would be done by nick sharing across different bare JIDs</td>
            </tr>
            <tr>
              <td>??:</td>
              <td>is that a general MUC problem or a nick sharing problem</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>??</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>that is true, on the other hand I have a mild concern about MUC proxying solution becoming a massive abuse magnet</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>more often than not, when they do want to share the role they still want to have their own JID active in a room</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>the reason I don't want to introduce a middle ware that is a JID proxy is that the real JID is not exposed to a chat room, so that if I want to ban Kev from the chat room then a JID proxy would allow Kev to still manage to connect to the room</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>what i'm proposing is that JID proxy would be performed by a muc service, it hands out a JId...???</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>so your differnt nodes in a MUC2 hash messages, we should just give them URNs and avoid using short names like 'muc2#messages' - everytime we try that it comes back to bite us</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>agreed, those things were hacks from before we knew what we were doing</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>you have a MUC2 hash message, if you want the chat forms in this, it would be a MUC2 chat message</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>you would use both messages and chat forms, you would publish the chat forms node and then you publish a reference to the node</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>what are chat forms</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>these are things like "send a medivac", they are big in certain communities</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>they are things you use when people are either dead or dying; what I'm wondering is.. we want them in the msg stream anyways but we don't want them poluting clients that don't want them</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>???</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>the reason why I do think it matters is that I'm trying to get the overal design and for most I do, a subj is not a message it's a different thing, a presence is kinda as it's a stream but it's not a message,</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>yes, the easiest case to understand, is that someone places an image into the stream and being able to centrally handle/do this, now for images there is a potentially interesting case is that they can be large and for large things having them by reference seems to make sense</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>so what does my client that doesn't support images see</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>that depeneds on the additional data that would be sent along with the image reference. one of the things that we want is to have a message that has a reference to something else that the client can then fetch, what matters is not the immediate format but that there be a way to do "hey client, go look over there" and that there be a framework</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>the case of someone posting a huge GIF that may have to be downloaded</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>if it's done by reference, you got the URL and can go outside of XMPP to retrieve it</td>
            </tr>
            <tr>
              <td>Lance:</td>
              <td>we have jingle-pub for similar purposes - <a
                  href="http://xmpp.org/extensions/xep-0358.html"
                  >http://xmpp.org/extensions/xep-0358.html</a></td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>what i'm driving at for these references is that a client that understands images, the example, it's going to potentially subscribe to the images node of the MUC and it can reassemble the message stream and then say "oh, kev said hello and then someone sent an image and then someone replied" but if you have a ref then the ref has to be the sequence of record so that you have to upload and then insert the ref into the stream</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>yes</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>for example a github commit record, these kind of integrations can now be seperated out would we add ref to them for these</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>well, it depends on whether they are wanted to be in the reference stream, for say a large image node, it could be subscribed to</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>you could sub to it for notif only</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>for early days of group chat we had "ralphm went away in a puff of smoke" but we really don't need them, although we miss them as they were a lot fun</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>if we were to take msg changes and display them in the stream, if we are going to do that then the client will have to insert them into the stream</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>presence doesn't have to be reflected in the stream</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>???</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>you still need references in some of the examples as they are outside of the room, you still need the reference</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>oh, ok - it might nice to publish the form to the room, the usecase of refereing to something outside of the room may be a side issue to this</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>arguing the point that it doesn't matter, we know that it may be a reference to an outside stream item and that someone will be pub to a node, the detail is that if you arereferencing something that is in the muc's nodes can be handled later</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>it can be handled out side of the muc and can be handled by the application, it seems that it's not something that needs to be specified</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>trying to get a handle on the overall design philosophy</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>the overall architecture is clear and this is a detail, he wants to get a general agreement that the text he has wrotten is not stupid and that if people can help and implement and that this can then be proven as handling this usecase</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>this is ??? ground breaking and we will be able to build it and he is worried that the use cases are covered for the long term and we will ge the usability we want</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>if we quickly try to hack something we will be able to discover the edge cases and flaws that are not obvious immediately</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>if we have mulitple streams will we be able to unify the streams and if we have multiple we would need ordering would that be done with timestamps</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>for the client in the room, it's just received order; when not in the room, you would use the forwarded time stamps that are provided by MAM</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>and if you have two timestamps do you resolve that by order of receipt - I would not be able to tell if ??? so ordering by the client would be ???</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td></td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>that sounds fair, when you pub to a pubsub service does it happen to serialize ???</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>when you publish to a muc you serialize across the service</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>it has to be seriliazed across a service and we cannot have eventual consistency convergence across different muc services</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>??? about two cluster nodes ??? nodes ???</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>every node that is created is associated to the room root node so wouldn't they have to be associated? then how do you figure out how different nodes / streams are associated</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>if one person in muc1 rooms joins and then you send a message, you will get eventual convergencie</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>in muc1 serialization would be done per room and not per service</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>you still have it per service ????</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>serialization / ordering in MAM is problematic</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>a client would need to define ordering</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>do we do sub-second timestamps</td>
            </tr>
            <tr>
              <td>Sam:</td>
              <td>you can always make the timestampls less and less</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>equally the problem to solve is not sycn across the messages - this is slithly less of a problem than temporal ordering</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>there are a few use cases where someone needs to know the precise ordering to prove something authoritatively</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>anything that is done machine to machine, and in certain cases that machine use cases you need precise ordering</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td></td>
            </tr>
            <tr>
              <td>Matt:</td>
              <td>even for the human use case - auditing and logging</td>
            </tr>
            <tr>
              <td>Sam:</td>
              <td>for example, turn on guest access, can't see messages before then - might be security implications</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>time is interesting - leap seconds and such</td>
            </tr>
            <tr>
              <td>Matthew:</td>
              <td>timestamps should be only FYI</td>
            </tr>
            <tr>
              <td>Sam:</td>
              <td>also system-dependent (e.g., leap seconds on BSD vs. Linux)</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>any other suggestions?</td>
            </tr>
            <tr>
              <td>Bear:</td>
              <td>in ops, set on system side and don't depend on client timestamps</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>an alternative, why not have all events in one node? clients can filter</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>why not have a #events node for sync - I assert that for vast majority of use cases, sub-second stuff is not needed</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>???</td>
            </tr>
            <tr>
              <td>Bear:</td>
              <td>in most distributed systems, use sequence number - for tighter precision, receive time vector clock from a central node that handles sequencing that all of the nodes subscribe against</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>if I understand correctly, a central synchronization service could have its own node in the room</td>
            </tr>
            <tr>
              <td>Bear:</td>
              <td>???</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>clients care about the presentation, why not just do it the right way the first time?</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>because it matters only when you're in the room, reconstruction is a different thing</td>
            </tr>
            <tr>
              <td>Matthew:</td>
              <td>you're describing the MUC1 behavior as desirable, but I'm not sure it is - can use subscription options to filter</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>we don't get the benefits of using PubSub, configuring separate configs for different data streams, etc.</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>agreed</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>for systems that require that level of auditing, they can provide that service with a separate meta node</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>isn't that just the root node?</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>potentially - if have MAM on the service, you get things in order - could add a form field to MAM for filtering</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>I'm not sure that the only examples are for historical reconstruction</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>if you're live, you depend on received order</td>
            </tr>
            <tr>
              <td>Bear:</td>
              <td>you're pushing precise ordering to MAM instead of MUC2</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>???</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>???</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>is this live or for MAM queries?</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>we do need to sync MAM to the live stream</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>not really, because we have IDs - when you're live, you receive what's live, and you can make MAM requests to get things before that happened</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>would be nice to have sequence ID in MAM responses</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>you have that because MAM responses are ordered by ID</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>which is why in the case where you are required to have precise ordering you do a MAM query and receive the order based on IDs</td>
            </tr>
            <tr>
              <td colspan="2"><-- new topic --></td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>you have an occupants node, what is the difference between that and it's subscribers, the reason I ask is because buddycloud handles the who is in this channel(room) by looking at the subscribers</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>because you may have diff subs for each node in a service and potentially you may want to have some subs who are not participants</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>is that the invisible observers, what does occupancy mean</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>it means tht you are a mmember of the room, because what happens in modern chat severices is that your not only a member only byt you also a member of a group and contains additional meta info about the subscriber/member</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>ok, if I publish my occupancy to the occupants</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>you don't</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>I don't so this is automatically maintained</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>yes, what happens is that ... ignoring the fact that there may be admin cases to this, what happens is that you send some variation of a join element to the room which is possilby a sub to a node (or something) then the muc service does something based on this and one of the things it does is add the relevant meta informtionto the occupants node for you and tho this is pbusub and we want to use pbusub services for the sake of this ext an for the sake of this data and these are nodes whose contents are generated automatically - - and indeed the message node may be published (generated) automatically - - so I think all of the standard nodes will be server maintained</td>
            </tr>
            <tr>
              <td colspan="2"><-- new topic --></td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>ok, that seems reasonable, next question, you got subject but you also got topic - is the room's topic not just a config item</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>you have subject and you have config - isn't the room subject just part of the config?</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>I would argue that it's just data and not meta data and this is not something he does give a high F value to</td>
            </tr>
            <tr>
              <td>Sam:</td>
              <td>would be nice to have ability to set friendly room name</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>we have that in MUC1 but it's part of the room configuration and only admins can get at it</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>the right way of doing this is to have a config and a meta data node where the meta data node is the room name, subject and the config is something only the admins of a room would write to or even read</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>the reason to have subject in the event stream is that it's the way it is in MUC1 and that is how Kev's brain is wired - there's a question of whether we want a node per metadatum</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>for comparison, buddycloud for config and for things like rooms name and description, he doesn't think is great but he thinks there is some degree of merit - he is not sure why you need a config node but a meta data node means you can reconstruct topic changes</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>some people care a great deal about what state exists in a point in time so exposing this data as a node we have a way of extracting the config's change history</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>that's reasonable</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>anything that could be a node and be could be fetched historically we just make them nodes explicitly</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>do you expect the client to be able to make changes to the config based on auth level, from readers point of view can they get all of the config node chnages or only filtered one</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>for a general case you not let them sub to the node but that anything that is necessary for clients to change is that that datum go into a different node, changes to config would be done via data form and then the service would push data items into the proper nodes</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>might not want to mix security-related items - e.g., blocklist or spam-fighting</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>split things logically depending on whether it's in the same "security domain"</td>
            </tr>
            <tr>
              <td>Bear:</td>
              <td>knowledge of item IDs can be based on role</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>you could do that but we don't have infrastructure for that now - who is able to read was controlled in MUC1</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>in MUC1 we had events that we told the client that we thought were of interest, the room is non-anon, the room is being logged</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>it was very adhoc who implmeneted them</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>what we could do is not that this is an open issue and then circle back to talk about this on the thought that you could do an MUC2 implementation that has totally open config and then circle back to resolve this issue</td>
            </tr>
            <tr>
              <td>AI:</td>
              <td>Kev logs an open issue</td>
            </tr>
            <tr>
              <td colspan="2"><-- new topic --></td>
            </tr>
            <tr>
              <td>Sam:</td>
              <td>what is the story for private msgs in semi-autonomous mucs</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>for non-anon it's straight forward you have the full jid and nothing is hidden; for semi-anon you have the fake jids that the room creates for you so you use them for private - if you want to allow it or not you disal;low it in config</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>I'm curious if we do want to tie the anon status of the room to the ??? and that may or not be desirable, it seems interesting that the room may want to track this status - I may want to ???</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>there is nothing that stops a muc service from making the fake jid from acting like a real jid so that all of the things that happen with a real jid would happen - the advantage to doing that for muc1 was that the nicks were associated to a jid, in muc2 they (the nick) survive as long as they are wanted by the muc2 service</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>???</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>why would you want to do that</td>
            </tr>
            <tr>
              <td>Waqs:</td>
              <td>some of the use cases have that some people discussing that a mam for my nick and that would let me get archive of my messages because I have spun up a new client</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>you would do that from your jid's own mam archive - and now that the jids are now longer lived in muc2 that makes more sense - - ?? a non-muc2 client could connect, see the nick history in it's mam and then continue the conversation all without knowing that it's a muc2 room</td>
            </tr>
            <tr>
              <td>Waqas</td>
              <td>?? anon proxy ??</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>yes your wrong in that you don't want to go there, if you tie it to a muc room the muc knows about the psued-anon and it can still do blocking based on real jid and show the real jid to the admin and it still knows what the server is so it can do spam prevention, where if you have a anonymizing proxy you lose a lot of that</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>and the whole anonymzing proxy that exists ???</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td></td>
            </tr>
            <tr>
              <td>Sam:</td>
              <td>this is interesting that the room is no longer the source of the anonymity but the user's connection to the muc2 service</td>
            </tr>
            <tr>
              <td>Lance:</td>
              <td>you could have only admins be the ones who are using anonymous proxies</td>
            </tr>
            <tr>
              <td>Sam:</td>
              <td>leaves that up to server policy</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>intersection of server policy and user preference - you discover anonymity you discover it only after you've joined</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>that would no longer be the case because in Muc2 the config is discoverable so you would be able to pull the config and know that</td>
            </tr>
            <tr>
              <td>Dave:</td>
              <td>you can have anon requirements as a property of your subscribe/join and if the service doesn't want to support that or grant it , you will get rejected, which is neat and tidy</td>
            </tr>
            <tr>
              <td>Sam:</td>
              <td>it's nice and atomic, you will get a discrete/distinct error</td>
            </tr>
            <tr>
              <td colspan="2"><-- short break --></td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>I'm happy with MUC2 but it will improve through more questions</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>at a higher level it would be good to talk with people who have been trying to work around issues with muc1 and if that muc2 solves those issues</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>certainly he has floated this idea at fosdem that this does address those issues that he has heard of</td>
            </tr>
            <tr>
              <td>Waqas:</td>
              <td>the only thing that he is thinking about is references as that is clearly a non-atomic operation and does that matter</td>
            </tr>
            <tr>
              <td>Kev:</td>
              <td>what your doing is making a resource available and then you are referencing it</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>i'm happy and that it covers most of the use cases that he needs and that it should be possible to offer a old muc service to interface to muc2</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>mlink doesn't do muc over xep60 and it has an abstracted pubsub interface and it's not quite the same thing</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>one of the details of this that makes this work very well and maybe dav'es dog acn proxy for him, is that it works much better if you implement "don't do pubsub from your client, pubsub from your account" because if you have that things get much better because you can instead of linking nodes that you subscribe to, you can finally solve "which rooms do I know" "which rooms should I be in" - having admins put you in muc rooms, so like sysadmins may want to shove your roster to you, with this protocol because your client doesn't , let me rephrase, with muc1 your client knows what rooms your in because it has to sub to them, with muc2 it knows because the client asks the server so the sys admin could put you into a muc2 room and then the client will know that</td>
            </tr>
            <tr>
              <td>Peter:</td>
              <td>we've had many cases where that would be helpful (e.g., online education system)</td>
            </tr>
            <tr>
              <td>Lance:</td>
              <td>we abused the roster for that</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>there is another point, muc2 doesn't go into yuor roster, on the basis that sending your presence to a muc is ???</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>that is something that I tried to do for a client because of the number of rooms, it did not work for muc1 because the initial presence did not have a resource, but if it had worked lance would have been very happy</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>do we want to make this the model for muc2, do wwe simple say you put muc2 in your roster</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>yes</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>i'm aware that this may have clients have to mix muc1 and muc2 in the roster, how bad is that</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>I don't see it as a problem as it's not the humans managing the roster, it's the same as a muc1 room because you don't know it's not a contact until you query all of your contacts</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>but for muc2 you do because you do pubsub from the account, not from the client</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>???</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>kind of but as a muc2 client your going to need to ask what is the list of your muc2 rooms anyways because you will want to know that at startup</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>what is the benefit of knowing in the roster</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>because it keeps you from having to send out presence requests</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>should that be the muc2 room in the roster or should that be the muc2 service</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I think it should be room, not service, because you want to send presence to the room - this feels like a general XMPP model and keep to it</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>if I'm a remote admin and I add Lance to the room, what happens?</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>you don't add, you invite - maybe for muc2 we merge the old direct and mediate invites</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>you can't invite anon can you</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>in theory one could invite anon but I don't think you want to, in principle this invite could be anon or come from the room, we should speak that the invite ??? after telling the muc that your going to invite this person, leave open as implementation, you could have a marker for invites that the muc has intercepted - {???} and add invitees to subscriber node but not occupant node</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>he wants to see what rooms he has been invited to after coming back from offline, the roster was the only place to see/store this information</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>the muc2 service should be able to do this by querying the nodes for rooms that the jid is sub'd to - this works if we're using pubsub on account</td>
            </tr>
            <tr>
              <td colspan="2"><-- pubsub on account --></td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>the basic premise is that currently all pubsub sub management is to the room because you do it with full jids or bare jid subs that you subcribe from your client and the only thing that knows is the client that did the sub, bare jid so that the client is the one that knows where it needs to go or you sub full jid and ???</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>you ask your server to sub your bare jid, your server knows about subs and then you do a reverse PEP thing on the client side of your server where your server sends the pubsub notifications to your client so it's your server that is doing the de-muxing on the notifications based on the clients that want them. if you sub while offline the server knows about the subs so the account will be received as each muc msg once, so your server knows everythign and your client can ask your server everything and you now have a way of finding out what subs you have, additionly adv if your server has Mam you can also capture all of the notifications while you wwere offline</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>helpful because your local MAM store can be quite large even if remote (e.g., MUC) server has limited storage</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>??? where you have to query your own mam server and you don't care that other servers dont have mam support</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>it will work without it but if you can still do full jid subs to muc2 however it will be much uglier than ???</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>would you expect your server to resync if s2s goes down</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I haven't assumed that</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>if I was writing a client then i would not ever have to care about that again</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>we should get Fritzy to write up that pubsub proxy idea from FOSDEM a few years ago</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>wasn't fritzy's pubsub proxy like a pubsub inbox?</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>yes</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>do hipchat and slack at least basically have the same model</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>the model is the same in that slack you have per scene views and you share everything between devices and you can post rubbish to rooms and you can comment on things hanging off the side of rooms, if sam says that hipchat has the same model of slack then we can also now check-off most of the boxes that hipchat needs or wants to support</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>I'm reasonably sure we've ticked off most of the boxes that we support or want to support in the near future - big one is s2s synchronization, which we don't have right now</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>the ability for your server to resync if it wants to requires no extra protocol is important, if we're using pubsub from account</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>the arbitrary meta data is also an important one - we tack on a lot of extra data, the clustering story is good</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>does the pubsub proxy need to be muc-aware?</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I think it might end up needing to be aware depending on how subs are handled, the open question is are we making our join stanza for the muc a simple modified xep60 stanza then the pubsub account knows about the muc - not quite clear to me and we will have to solve this as the first things - whether the pubsub sub for a join works</td>
            </tr>
            <tr>
              <td>ralphm:</td>
              <td>my preference would be to have a special MUC join instead of</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>subscribe should be different from available</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>sub is already a different operation than a join</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>what are you sub to because of all the nodes available</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>you sub to the root node, which could give you default subs to the various sub-nodes</td>
            </tr>
            <tr>
              <td>ralphm:</td>
              <td>if you do a specific join using something other than a pubsub sub you can do something silimiar to an auto-sub for pep. so in pep when you send presence to an entity ??? if you have pep you baiscally sub to all the nodes and then you have a caps filter on then to you effectively sub to the things you want to see, if you do that for muc2 then you would have an explicit join trigger something similiar</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>we do the rev for muc2 because in muc2 we tie it to a specific account and if you use your server to act as a pubsub proxy (or whatever)</td>
            </tr>
            <tr>
              <td>ralphm:</td>
              <td>your server will always get everything even if none of the clients require everything?</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>it will always get all of the defaults unless you explicity say otherwise, if you have a client ??? your other client in the mam archive is always on the client then the other client ???</td>
            </tr>
            <tr>
              <td>ralphm:</td>
              <td>so assumption is that MAM is only local?</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>the possibility is that you can have both local and remote</td>
            </tr>
            <tr>
              <td>ralphm:</td>
              <td>in that case you will always get the history</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>I'm with ralph, I think we'll need some equivalent of +notify - I subscribe to everything but here's what I want</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>this does move greatly away from the pubsub acct model</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>no, we have to solve this even for the pubsub acct model anyways, if you come online for the first time your pubsub acct service will want to sub to all possible nodes</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>its a diff problem in a sense, I think I agree with the message your saying but I don't think it's fully expressed - what you need to solve is a way for your server for your account is a way to sub to a remote service it's that your acct, be it pep or a muc2, needs to know which subs you want and then receive the super set of what you want</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>ah, which isn't waht I said, we have to make sure that we are able to sub to a subset of nodes on a remote service, like what it works now but in a sensible way</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>the muc2 proto xep says you can sub to individual nodes, but if you do a default sub to a root node you will get all of the nodes that are defined in muc2 and if you want to their will be a way to limit/filter those nodes</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>we need a way to say I sub to muc2 and *these* kind of nodes are what I want to see</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>ProtoXEP says "Send pubsub subscriptionish stanza to the room. By default subscribes to all the 'standard' nodes, but can specify just those required. Server injects a new item into #occupants automatically."</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>with that caveat that what exists is nodes that what exist now or are created in the future, we may not have an elephant node but if we want to create one then that the clients that want to see the elephant node then they will get sub'd to that node</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>to clarify, we have the root node and the default list of nodes, so what happens if the elephant node is added to the default set</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>no, the default set is defined by muc2 and does not change</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>but what about custom nodes so what happens if we need a large image node and do we make it default and will it ever be a default</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>we don't make a default, if you want to sub to the large image node then you include that namespace in your sub request</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>ok, so the defaults are static</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>we shouldn't have to have a default and that clients should specifty what streams they want to sub to</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I don't see the harm and it seems more elegant, but I don't see a compelling reason why we would not make it explicit each time</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>the big thing would be indicating that you don't want a sub to one of the default node</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>what worries me about having a default, then how in years to come how can we respond to the question "how could not have known how awesome an elephant node was", it will make it harder to introduce new best practices nodes</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>that's fine</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>what to focus on next?</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>please make mental implementations :</td>
              <td>-)</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>do we have a way to subscribe to multiple nodes simultaneously?</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>the answer is no and we do need to address that, there is one other thing, give a muc2 domain you can then try to discover the muc1 domain - he would like that to be the same so that a muc2 implementation can just provide the muc1 domain</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I'm proposing we don't do that in the spec - I would rather we spelled out that it's not necessary and have clients able to do the fallback. It's easier to make these logically separate, mostly for the disco cases. If an implementation figures out to do that, more power to them.</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>ok, so the counter argument is: here is the address of a room, presumably that is the address of a muc2 room and then either their client speaks muc2 so that it gets that and a muc1 client doesn't even know how to use that muc2 address, the reverse point solution would be to always give out the muc1 address</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>assuming that a stable address is required</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>I would implement this by doing muc1 join to the service and receive a presence error with a redirect</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>yes, that would work for the case where you are giving out addresses directly but currently no clients are following redirects</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>don't depend on the fact that an older muc1 client would know how to handle a new muc2 related protocol to work properly</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>not really - your case was not disco, but you're given an address of a room</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>room discovery principles are fine</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>if you're given muc2 address, room could send message to client saying "here's a muc1 room over here" (or an invite)</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>what I would like to see is if they try and join with a muc1 address that they get a subscription tot he muc2 room with a lifetime presence</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>if you want to implement that clever way, you are entirely free to do that, but he wants it to be considered a failure???</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>unless we hear otherwise from server devs, I'd prefer to keep them separate</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>so the case that i'm seeing is the disco one, I suppose that we could start off assuming that it's impossible and then we ned up with a crappy client exp, rather let's enumerate the points where it won't work and if we can address them as solvable</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>the way I see it is, the protocols don't overlap at all so I don't see a need for separate domains</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>I agreee with everything you say but the point of overlap, we know that there is overlap with disco, but what we don't know is how many clients use disco for</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>for the domain is easy, ???</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>it works for both of the protocols and no one cares about what we put into the ???</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>only risk is difference between getting JIDs and getting pubsub nodes back from the disco query to the room</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>do the clients do anything with the response other than displaying it</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>muc2 we could be saying that this subset of the protocol will work</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>I don't think we ever made guaratees that disco would only return certain information</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>we kind of do have to deal with backward compat issues</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>for occupants, that's supposed to be under its own node</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>right, there's a special occupants node that tells you who is here</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>it's not just things hanging off of the node</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>can he request that someone with an easily hackable server with an easy hackable language do this and then discover how a client handles it</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>I can trivially do that</td>
            </tr>
            <tr>
              <td colspan="2"><-- lunch break --></td>
            </tr>
            <tr>
              <td colspan="2"
                >related topic: mentions - out of scope for now, might need a separate spec</td>
            </tr>
            <tr>
              <td colspan="2"
                >Waqas and Matthew talked about how to do this using existing mod_muc and it appears to map well</td>
            </tr>
            <tr>
              <td colspan="2">Radical change of topic...</td>
            </tr>
            <tr>
              <td colspan="2">MAM & Carbons</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I thought the spec was in shape for moving to Draft</td>
            </tr>
            <tr>
              <td>matt:</td>
              <td>there are things that are essential that are not in the revision, namely the ?? itself is not in there</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>it's kind of in there</td>
            </tr>
            <tr>
              <td>matt:</td>
              <td>that was sneaky</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>it also says that there may be future profiles of carbon that will say exactly should be carbon'd so I think that mamsub will be come a profile of carbons including messages back to yourself</td>
            </tr>
            <tr>
              <td>matt:</td>
              <td>I didn't get that would be the intention of that</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>i really don't want carbons to yourself</td>
            </tr>
            <tr>
              <td>matt:</td>
              <td>??</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>doesn't want that by default at all, if it's negotiated that's fine</td>
            </tr>
            <tr>
              <td>matt:</td>
              <td>why</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>because it takes us down an alley we don't want to visit</td>
            </tr>
            <tr>
              <td>matt:</td>
              <td>??</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>if someone wants to do additional negotiations that is fine but I don't want to introduce this at this stage of the draft, he would rather deal with this in another spec</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>do what</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>blind reflections</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>speaking of reflections, is it ok to have in muc2</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>that is kind of the way it's always been and also in pubsub, so yea your probably to get it back</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I once chatted with a user community that they thought it was very useful to have echoing, say compared to irc, that your message is useful to have appear in the return stream</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>I don't mind keeping it in the places where it has been, but he doesn't want to introduce it to carbons or places where it isn't currently</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I don't see why that is a problem, your already going to get reflections of other clients</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>but not your own, none of the existing carbon imple send it back</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>clients right now will show your messages twice because it won't know to igore</td>
            </tr>
            <tr>
              <td>matt:</td>
              <td>are you worried about this because of interop grounds</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>yes</td>
            </tr>
            <tr>
              <td>matt:</td>
              <td>that is a different argument and do you have a solution</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>the reservation to making this change for carbons was "here is what you should be doing but it was non-normative" because we didn't want to do the namespace change but that it was compatible to the old way by making a new namespace a requirement - also allowing us to do a future profile that allowed it by negotiation</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I don't see why this is a problem because we left it up to server implementations to do it - any server that does it or chooses not, it will be not a useful implementation</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>yes, but if you do include reflects then that also change which category of clients get carbons especially if it's only some servers and handling of duplicates will have to be implemented</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>it seems that this may a bit of a surprise because of what carbons xep now say</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>??</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>what is the problem in the current xep</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>because people can do reflect in the current xep</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>what do you think the problem is in the current xep? it allows reflection if negotiated</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>I'm not blocking current negotiations as long as it's not by default - any reflection *must* be by negotiations</td>
            </tr>
            <tr>
              <td>matt miller:</td>
              <td>the spec does not discuss that</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>nothing says you may not or may, it's just not mentioned</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>ok, then lets just say you don't do reflections on outgoing messages</td>
            </tr>
            <tr>
              <td>matt:</td>
              <td>but that defeats the use case of doing it for mam</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>then we should make the current rules even more clear</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>if the imple turns out to be rubbish then ...</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>???</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>I agree with Dave in the sense that this is how implementers have done things now</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>that is why we updated the xep to follow what some imple did</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>with the namespace bump?</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>without</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>??</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>I have a proposal (other is use of hints) - bite the bullet, fix things, and see what happens</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>if we are bumping the namespace then we may as well do that for mam sync, we didn't because we already had carbon deployed</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>my argument is that existing impls can relatively easily update, whereas implementing a new protocol is a lot more work</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>there is no need to have a new namespace or anything mamsub or mamsub by carbons is ??? if we are updating carbons we may as well update everything that is needed</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>I like that idea</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>it's just carbons and MAM all the way</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>thats' right it just means that instead of leaving it for the current version we say instead we say explitly what stanzas get</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>it sounds like Dave would like that</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>no, I just want to say no reflect without negotiations</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>I'm assuming this would include negotiation</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>all I want to do is say no reflect without nego and then ship carbons and if we want another spec that says that we want to nego then that's a whole other spec</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>I think that mam sub is irrelevant - what do you think about bumping the namespace</td>
            </tr>
            <tr>
              <td rowspan="2">dave:</td>
              <td>I think we're one line of text from shipping this - let's do that and figure out reflection, MAM-sub, hinting, etc. - I suspect that's a large bit of work</td>
            </tr>
            <tr>
              <td>matthew it sounds like it's no longer one of text because it sounds like you disagree with the revision about non-nego reflection change</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>yes, I'm saying you add one line that ways "no reflection without negotiation" - we can safely add that and we're done</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>so you want to leave carbons as is, the changes to carbon are pretty small and they ...</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>it sounds like we have sufficient disagreement and that we go back to our prev state</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>this is really annoying lots of people that we have't been able to solve this simple problem</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>i'm not blocking any further work, i'm just saying that we have something that with a single line that it will document existing work precisely</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>carbons is only half of the problem that people are trying to solve, but we've still got a lot of things still needing to be solved</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>that's fine and carbons doesn't solve video chats and conferences</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>the point of going to draft is not saying we need incremental additions</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>no we are saying that this protocol is stable, and if you want to add another spec to tighten it down we can, not a problem</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>if we tie up this stuff now, people will define something else and we could have an entirely different carbons replacement spec (Florian's message routing protocol)</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>I don't understand why if we do carbons now and if we have another xep that adds the nego part about reflects</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>that would be carbons2, I don't see how that would be neatly way</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>another way, what would be the result of not pushing carbons in the current state to draft</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>I think we can push carbons to draft in another week</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>matthew's point is that people want mam+carbons and this doesn't solve that problem</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>carbons + mam is part of one problem, they need to work alongside each other (MAM doesn't solve the offline problem to send everything to all devices)</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>the only tweak we need to make is to apply that they ???</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>I'm assuming Dave is also against hints in carbons because that's a further modification</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>the discussion on the list ended up that we should do hints because it's own xep and carbons private thing that seemed to be the consensus</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>I don't know that they mean slightly different things - at the end of the day, all that's needed is the ability to turn carbons off for a particular message</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>but private controls the senders end but the no copy hint controls the other end</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>I was not aware that <private/>controls the sender's end</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>that is not quite the only that is needed because that is ??? because your allowed to hide parts of your archive from your client</td>
            </tr>
            <tr>
              <td>matt miller:</td>
              <td>I kind of agree with Dave, but it does solve a fair amount - shipping carbons seems like a good idea and handling incrementals is something we've done many times</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>is that saying that moving carbons to draft without specifiying what the routing rules are and despite knowing what the routing rules are and then adding them to a later change to just add the routing bits we know are</td>
            </tr>
            <tr>
              <td>matt miller:</td>
              <td>I was under the impression that the PR documented what impls are doing today but leaving open future flexibility</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>if we did make it more specific that would imply that we have to bump the namespace</td>
            </tr>
            <tr>
              <td>matt miller:</td>
              <td>do we have to bump the namespace if it's what people are doing now?</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>no in that case there would be a strong argument to not bump it but the changes we're talking about are not what impls are doing right now</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>and the reasons to want to specify it further is that for as long as your client is online you will have a copy of everything and if your offline you have to just do a reseycn and then your update carbons and your archive is accurate</td>
            </tr>
            <tr>
              <td>matt miller:</td>
              <td>I suggest that we ship and fix with increment or replace</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>"ship and iterate"</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>for the record, I agree with dave with that at the moment if we say it is ok for a server to start sending reflections and that will break existing clients, the enabling carbons is negotiated so we can now insert a new item to say "allow reflects" and that is all that we should have to need</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>if we change carbons to "selfie" then everyone will implement it right away</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I'm about 4 or 5 on the "F" scale</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>he is quite a large number of Fs to ship</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>i'm the same that we ship something now that works</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>so we have been talking about it for 18 months so...</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>I think we're two small changes away</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>I agree that we need to solve the full problem</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>there are overlapping issues here</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>I've already said that he wants to ship what we already have and then fix it later</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>do you just mean advance this to Draft?</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>yes advance to draft</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>what does that accomplish?</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>it means that as an org we can recommend that it can be implemented</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>???</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>my reading of XEP-0001 is that we shouldn't advance to Draft if we expect any change that would require a namespace bump</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>ok, that's fine and that leads to the questiohn that if we make the changes do we need to make a namespace bump even if adding an attribute</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>why would that need a namespace bump?</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>then I need may have been a misreading of a mailing list post</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>I think existing clients would get the same behaviour so would not require a namespace</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>then we add in this flag into the enable attribute to say that reflection is on or off (default off) and that means we don't need to bump namespace</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>I don't think we want to just add negotiation because you're going to shoot yourselves in your foot because then you want an archival ID</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>that's fine then you can specify all of this in another xep</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>is that a problem/part of carbon</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td></td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>I'm wondering if we are making this a bigger deal than it is, why does it matter if selfie negotiation is in another spec?</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>issue isn't that, but that if we move Carbons to Draft means we think it's ready</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>if we go to draft with the existing text, if we go to draft today, then we would want to do that knowing that we wouldn't make anymore changes</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>we are always making changes, but we don't move to draft if we *know* there are changes that will be coming, we always are making small changes</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>if we take the mam spec and we say if you are going to be using carbons and mam, ...</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>then that would be a new xep, let's take the parts that we are not having consensus on and that would define what mam and carbons interoperate and move to a new xep</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>that seems OK because we want to include things like including reflected IDs</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>i'll be modestly happy that it seems we have acheived some kind of consensus with that new xep</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>so no selfies by default, handled via other spec</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>we add another line saying that we think other specs will be needed to specify interaction with archiving</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>that is what i'm trying to avoid - linking them, even if mam didn't exist reflecting your id and ?? is useful and the reason we didn't do it sooner is because it was already implemented</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>and you need an archive ID as well</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>we already have that spec'd out</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>there is no need to say this spec will change</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>all that kev was saying was that we should add one line saying "watch this space"</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>we don't need that as long as we can say "these rules may change later"</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>sure</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>what I really think we *want* clients to implement is a solution that works with archiving, fast MAM resync with IDs, etc. - I think that's uncontentious. Is there a danger that when we say "carbons is great" we cause trouble for ourselves down the road when later one we say "you need something else"?</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>its not something else, but something in addition</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>any implementation of it will be next to something, it could be even better after we figure out what it is really</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>for the client side, i'm fairly convinced it doesn't make it even worse for mamsub, but for the server side i'm less convinced that there are any benefits for having an existing carbons ... what you meant to do was to ... other than having a hash defined for your namespace - concerned to have the servers get asked to do the work that they would have to reimplement it</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>the carbons spec as-is is a tiny amount of code on the server</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>I think this is a minor concern</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>it may not be a lot of code, but the tests used to make sure you don't have regressions and that must be complicated/large</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>nobody tests servers</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>*thanks dave for giving him something to fix legacy wise*</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>by and large it's a moot point because he isn't going to have a vote when it does arrive to the council</td>
            </tr>
            <tr>
              <td colspan="2">[ random discussion about compliance suites and such]</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>we have to make sure that no-store is ignore in MAM-sub</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>no-store and no-copy are equivalent</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>you want no-store to be ingored because ???</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>no-store and no-copy are equivalent, because ??? - whatever you copy, if it's for the puposes of mam sync it has to be in mam</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>if it's in the archive you have to have a copy, howerver if you have a copy and you know it's not in your archive ??</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>no-store is not the problem, but no-copy is ...</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>you would never get that message is that you ??</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>we should just do away with no-copy, when your doing mam sync ...</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>I'm fine with that - but why is <private/>in carbons anyway?</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>for things like OTR or IBB file transfers</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>nobody for IBB</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>and they wouldn't be in the archive?</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>if it wasn't in your archive you would expect to go to all copies if you were doing mamsub</td>
            </tr>
            <tr>
              <td>matthew:</td>
              <td>currently spec says <private/> applies to sending server and receiving server</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>I misread either the xep or the message ... but then yes...</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>if we do push the XEPs as-is, does that help us get more implementations?</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>Pidgin for example has had a patch waiting for awhile</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>does the xsf want them to implement what they currently have or the version that will be going to draft</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>I mean if I you know i'm a user using pidgin, and pidgin says they are not going to implement it because it's exxperimental..</td>
            </tr>
            <tr>
              <td>peter:</td>
              <td>we should find out what the hold up is - does not seem to be the standardization status of the specs</td>
            </tr>
            <tr>
              <td colspan="2"><-- new topic --></td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I don't think that our current read-markers stuff is the right solution - when we come to MAM + carbons we need this. And I am the only person who sometimes wishes to mark a chat message as unread?</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>I would prefer to just have a way to arbitrarily mark message ;-)</td>
            </tr>
            <tr>
              <td colspan="2">[scribe missed a bunch of conversation here]</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>I think the server can keep a count</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>I'm proposing that the client can tell the server "this is the last message I received", which we can do with carbons + message IDs, have a PEP node that you put items into?</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>then you need to query data when you log in</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>don't need an item per conversation, only an item per conversation with unread messages</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>if also store last message that any client received, then you know from that point onward everything is unread</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>I think that works</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>so need to update that every time you receive a message</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>doesn't need to be on every message</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>at that point it's kind of like a cross-client XEP-0198</td>
            </tr>
            <tr>
              <td>dave:</td>
              <td>but we're not dealing with order etc.</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>as part of normal history sync it gets messages from MAM</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>you log in, ask what's in the node, node says unread since this point, client clears that once messages are read</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>I like this and it's consistent with our existing implementation</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>it gets better! if you do this and you do the global last-received ID, client can just request messages since any client was last online, that means resync is only 5 minutes of messages if you haven't been on your mobile in a month but you've been online at your desktop until just now</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>at lunch we talked about syncing recent conversations, not just messages - I think this will probably let us do that</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>sadly, no - however, I think we could define a way to query your MAM archive for JIDs with which you've had conversation</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>it'd be nice to get the list of open tabs</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>couldn't we do that with bookmarks?</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>we could do this with bookmarks but the UX I think people want is something close to what Lance describes - I'm wondering if we solve Lance's problem (who was I last talking to?) would that be enough, but do we really need to sync tab-open state across clients?</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>not just tabs, but conversations - if we did bookmarks over PEP then I think we have what we need, but we'd need private PEP nodes</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>how about chats with people not in your roster?</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>other clients would receive indication that the conversation is retracted and not show it</td>
            </tr>
            <tr>
              <td colspan="2"><-- Push / XEP-0357 - ></td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>it's done, we just need implementations</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>when do we need or expect to send push notifications?</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>servers push to backend services, which push to clients</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>client wants to receive a push if it's offline</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>but even if it's just in the background</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>basically push all the time</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>doesn't that result in duplicates?</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>can you suppress pushes on the client side?</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>yes, that's up to the client developer to figure out</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>one of my server developers said there was no point in client side indications, you only ever do push</td>
            </tr>
            <tr>
              <td>lance:</td>
              <td>you can't rely on push notifications or that it arrives in a timely manner (perhaps not even order)</td>
            </tr>
            <tr>
              <td>sam:</td>
              <td>CSI might help with other things (annoying presence or whatever)</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>my point wasn't "don't do CSI" but "don't disconnect completely"</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>how does this work on a server that's on an XMPP server off the 'net?</td>
            </tr>
            <tr>
              <td>waqas:</td>
              <td>I don't think so</td>
            </tr>
            <tr>
              <td>kev:</td>
              <td>in that case CSI would be more important</td>
            </tr>
          </tbody>
        </table>
      </div>
    </div>
  </body>
</html>


More information about the Summit mailing list