[Summit] a few notes from today

Peter Saint-Andre stpeter at stpeter.im
Mon Feb 7 16:19:08 CST 2011


Some folks (e.g., Ben Campbell) took notes of the morning session at
this URL:

http://typewith.me/AzdW3AgDSZ

The notes seem to be incomplete, but here is a paste...

###

XMPP Summit
February 7, 2011

XEP-0198

If you want an ack, request one

Drop the throttling? Move to a separate spec?

Nathan points out that it would be nice to have a spec for mobile best
practices

XEP-0286 (http://xmpp.org/extensions/xep-0286.html)

keep session resume

Joe H.: it would be nice if when you connect, the server / connection
manager could tell you where to reconnect to have the best chance of
getting your session state back

Distributed MUC

IRC-style

another possible requirement: improve latency

<discussion about joining two existing chatrooms>
Moderation could be interesting. Backchannel protocol for moderation
across two chatrooms?

Robert: When IRC reconnects, you always have a leaf connecting to hub. A
rejoining leaf replaces it's old link. IRC gets very complicated,
doesn't recommend reimplementing it. [didn't catch it all] Connections
between IRC servers act in a tree. One link going down could have
massive repercussions. Some settings from the hub and leaf are merged
(eg, bans, etc), but the hub generally "trumps" the leaf settings.

Florian: What if you have more than 2? What happens when you add a new
server to the room? How do you manage large numbers? Do you nead a
master room?

Dave: Military doesn't want master rooms. Servers may be out of contact
for weeks. Splits have to be autonomous. Servers can get "sunk".
"Surviveable" networks is literal. Abusive users don't happen in the
military.

Does military need more than some number of entities joining a clustered
room? Always ship to shore? Dave: Don't know numbers, but may be many
carrier groups or ships. Not strict ship-shore. Average comms guy in
Afghanistan have 5 diferent IRC channels running at a time.

StPeter: Running through proposals: XEP 281 (ShadowMUC), 282-
(MasterMUC), 289 (ProxyMUC) [Was there another one I missed?]

ShadowMUC - canonical source room, but room not required for
communication. Client can join shadow instances, or try to join source
and get redirected to a shadow. No support required by XMPP server.

[discussion of netsplit I missed]

MasterMUC - Slave intercepts traffic intended for master. May be more
IRC-ish. Master distributes traffic to slaves. Slaves send presence and
messages to master to be distributed to other slaves. XMPP server
support required to intercept traffic to master.

If net splits, slaves allow local coms, but not comm with other slaves.
[more[

ProxyMUC - Client discovers local mirror.  Join eg "room\40home at mirror"
Mirror joins home room via presence with extensions. Client sends things
to mirror, mirror to home, home to other mirrors. No mirror-mirror
communication.

netsplit undefined. Mirrors can deliver to local users in some
instances. Mirror policies undefined. Normal room naming.

Generalizing:

Need to harmonize terminology. Is home room access required for all
comms? Discussion indicates we need independent existence of remote rooms.

Is remote room an occupant of the home room, or something more formal?
Regular MUC with extensions, or something different? (Nice to use what
we have.)

Room naming? Do we need uniqueness? How do we communicate between home
and remote?

How do we handle replication? Policy negotiation, or just handle at
human level? When do we initiate it?

How do we handle partitioning/netsplit? restablish comms, resync,
history, room configs?

Who is interested enough to pay attention? Roughly 12. Who might review
specs? fair number, Implementers? Spec writers? (Fair number of all.)

Simon Tennant (Buddycloud): Special, niche use case. Why go down the MUC
approach? Isn't this pub-sub?

Ralph Meijer: Most of the complexity does not depend on the protocol.

Simon T: You can have a special web client that watches for stuff

Hildjj: If we had 60 when we defined 45, we might have done something
different.

[more Discussion about whether this could just be a pub-sub application.
I didn't catch any conclusions]

Ralph: Discussing the nature of seeing occupants in another room

Lee: Discusses how these occupants would be counted, and whether we'd be
able to see how many rooms were joined to a room, and how many domains.
[Not clear which, actually, to me]

--

Discussion on Multi-File Transfer. Peter shows slides.

also: transport-replace

Security Discussion....

discussions over the weekend about certificate publication, discovery

one PEP node with all keys
one item per key (separate item identifiers)
new XEP to optimize PEP using timestamps
each resource *may* have its own key

You can read certificate instead of key, maybe.

discover capabilities using CAPS

encryption using 3923-ish approach

whole-stanza signing
plaintext = UTF-8 serialized stanza

new slides

[note to self: get slides from Kurt]

we want optimistic signing...

###



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/summit/attachments/20110207/41b6aace/attachment.bin>


More information about the Summit mailing list