XSF Discussion - 2019-11-07

Ok email sent to members.

moparisthebest, you might want to show up for that meeting, your wish about council members might be granted :p

pep.: Oh I'll be there :)

pep.: My interpretation of the bylaws (and of XSF history) is that we convince 5% of members that this item needs to be added to the agenda and then we vote on it during normal voting process. Because voting has already started, instead we would hold a special meeting and the voting on the agenda items for that special meeting could be handled in the usual way (via memberbot). While we are doing this, we might as well clean up *all* instances where "in writing" does not mention electronic transmission...

Also note §5.10 Rules of Procedure - it's not clear to me that we actually need to amend the bylaws here, although it's always better to make these things clear in an official way or in the main rules document, not in another document that we need to reference separately.

For completeness, I posted to the members@ email list on these matters.

I don't quite understand latest changes related to oob. If I prefer to send data via SIMS should I also add oob data in the same stanza? What if I want to share multiple files at once, should I abandon oob at all?

rion, in the compliance suite?

Daniel: yep

rion: I don't think OOB forbids adding multiple elements

rion: also you should be happy that the latest change demoted OOB and SIMS from required to noteworthy

i mean for one it doesn’t force you to do anything. i think nobody is argueing that oob doesn’t have problems. however multiple people also feel like sims isn’t ready yet. that's why a number of implementations are still on oob (a lot of them have signaled willingness to switch once sims is ready though). if you just want recommendations on what to do; i'd just send multiple messages for mulitple files for now

I remember these talks a few days ago here about multiple OOBs. And honestly I don't remember what was the point of not doing this.

note i'm not defending that this is the proper, ideal way to handle that. but for now it should give you the best compat with other implementations

i really like what sims is trying to do. i really don’t like how it is doing that

Daniel: do you mean missing encryption for metadata?

Daniel: feel free to write a SIMS2 XEP that just defines a meta-data element with file_size, content_type, width, height, blurha_sh

i mean we rightfully complain about about oob being weird hacky, under specified legacy crap. but i highly suspect that if we implement sims now in 2 years we will have the same feelings about references

and that can be part of a message like OOB or attached-to a different message

rion, no. i'm worried about references

I don't think we need SIMS2, SIMS can just be updated can't it?

Kev: shouldn't somebody™ update References first?

Daniel: I know references needs cleaning, particularly with the split into references/fastening, but in principle this is sane isn't it? You're trying to say that here we have a reference to some other resource that we're sending you and is treated as part of the current flow, which is all that References does (post-split), so it seems like the right application.

Ge0rG: Yes, ^

i just want a sims that can be used stand alone. i’m ok with SIMS also being able to be used within a reference

as for me we still need to reference some text from sims. just to have the text for legacy clients while removing it for compliant. It works pretty well when this text has an http link for example (same link as in <source>), but in case of SIMS we remove the link and download one in <source> on our own with caching and checksum checking.

Daniel: Probably thinking of a different use case. What's the case for the 'stand alone' use?

Kev: sending a single file as a message

and when i mean stand alone i mean without referenceing a body

i don’t care about the syntax

just send a file without a body

Ah, so you still want it to be 'part of the conversation', just that there's no text attached?

yes

rion: how should the UI for that work out? show just the message, with an underlined link, and when you click the link it will open a popup with the media file?

So just https://xmpp.org/extensions/xep-0385.html#usecases-sending-photo Example 1 without the <body/> would do for your case Daniel?

Kev: in that case, wrapping it in <reference> doesn't make any sense

Kev, yes. but then there is no reference.

Or cry a tear of backwards compat and stick some fallback text there?

because what is begin and end refering to?

and you can’t have a reference without those attributes

Daniel: are there any open issues with SIMS that won't be solved by making <media-sharing> a direct child of <message>?

Implied entire <body>?

i mean i don’t really care about the syntax. but semantically it doesn’t make sense

Ge0rG, not that i'm aware of

and yes media-share as a direct child of message is kinda what i'm talking about when i say i want it stand alone

Speaking of semantics. You will want <body> to contain the original URL for legacy clients.

But then you also need a mechanism to tell modern clients that it can remove all of the body.

Ge0rG, yes. but then the reference thing becomes more problematic

because of what you just said

Ge0rG: kind of. for images/audio messeges I show the media directly (picture/player) right in the log. for other files I think to show a special button with file name and context menu to download/save us/etc. all the SIMS links are removed from body. remaining text is preserved as a description

Daniel: just the opposite. Let me draft an XML example.

<message to='julient@shakespeare.lit' from='romeo@montague.lit'> <body>https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg</body> <reference xmlns='urn:xmpp:reference:0' begin='0' end='77' type='data'> <media-sharing xmlns='urn:xmpp:sims:1'> <!-- stripped meta data --> <sources> <reference xmlns='urn:xmpp:reference:0' type='data' uri='https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg' /> </sources> </media-sharing> </reference> </message>

Daniel: make the reference reference the full body, that way a modern client will just replace the full body with the inline image

Ge0rG, where is it encoded that the body is just a fallback

and not a 'link' to show the image

like in example 1 of sims

We just need to mandate that in the XEP

that example doesn't make sense in that regard

maybe we need a new reference type / mode, "replace"

so when ever i reference the entire body it's a fallback?

s/all the SIMS links are removed from body/replaced with media elements/

when i reference just 90% of the body it's a link?

also that link usecase is super weird

rion: do you replace the referenced text with an inline representation of the media?

Daniel: I agree

who is going to enter that as a user like that

Ge0rG: yes

how would the ui even look like

Daniel: the only UI that makes sense is not to use link text but to place the media inline

so it will be rendered as "Look at the nice [picture] from the summit?"

<message to='julient@shakespeare.lit' from='romeo@montague.lit'> <body>Look at this nice view! https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg</body> <reference xmlns='urn:xmpp:reference:0' begin='24' end='101' type='data'> <media-sharing xmlns='urn:xmpp:sims:1'> <!-- stripped meta data --> <sources> <reference xmlns='urn:xmpp:reference:0' type='data' uri='https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg' /> </sources> </media-sharing> </reference> </message>

wtf?

> Look at this nice view! [Image]

Daniel: My thought in this case was that you would have a body that was http://picture, and the reference would be the full body, and the media-sharing would cover the metadata.

that's not what the examples says

Daniel: yes, the example doesn't make sense.

(am I repeating myself)

I mean, there is "Inline" in SIMS

Ge0rG, in your example will it be mandated that the text you are 'linking' must be an url?

Daniel: no. I would just recommend that, and mandate that the referenced part of the body, whatever it is, will be replaced by the media element

Daniel: making it an URL makes sense for legacy clients, if you use HTTP Upload

> Daniel: My thought in this case was that you would have a body that was http://picture, and the reference would be the full body, and the media-sharing would cover the metadata. i’m generally fine with that approach. but if the same xep also allows hot linking like in the example i need to somehow discover which it is going to be

if you use JFT, it would be something like "[the file I just shared]"

Daniel: looks like everybody here agrees that hot-linking doesn't make sense

so we agree that the xep isn’t ready yet?

that's all i said

Daniel: we've just gone beyond that, by identifying what needs to be changed: - mandate that the referenced text is replaced by the inline media. Done.

+ recommend to use the URI of the media in the referenced text

I don't think there's any need to mandate that bit of the UI, is there? Just to describe what the semantics of the referenced text are.

A client can then choose how to render it.

> + recommend to use the URI of the media in the referenced text that too

Kev: oh god no.

> mandate that the referenced text is replaced by the inline media. Done PR?

Kev, what are the client's other options in your mind?

I don't like open-choice standards

To show the message, including the link, with the image below it, for example.

are references going to be used somewhere else? or is references only going to be used for sims where it is (imho) 'ok' but not really ideal to use

A la Slack, Discord etc.

We've had a fair few of them, and we either ended up tightening them or it just became a mess or people adopted de-facto standards

MattJ: I think mandating UI behaviour in protocol standards is usually not right. It's not needed for interop.

It needs to be clear what the semantics of the protocol are, definitely, and it's currently not, but exactly where on the screen an image is rendered isn't needed here, I think.

In this case the semantics are clear - the text is a fallback for the media

Ah. I don't agree there.

It's more than a fallback when it's the URI identifying the media.

also did we cover rions mulitple files use case yet?

You might click it to open it in your browser, for example, or copy it to share with someone else.

Unfortunately, I can't keep going with this right now, have other work, but could we take this on list and I'll try to chime in later (and maybe see if Tobi has cycles to update SIMS with the outcomes).

Kev: if we define the semantics as "the referenced text is supposed to be replaced by the media", I would agree.

Kev: if we define the semantics as "this could be a URL, a link text or the verbatim string 'yaddayadda'", then good luck

dwd, "and that moreover we avoid doing this kind of thing if at all possible", I don't like resolutions that say "we should avoid doing this" when the alternative is not clear either. that means everybody is afraid and nothing ever changes

I guess we can add another agenda item to clarify this :) ✏

dwd: very nice Special Meeting Agenda mail! 👍

I managed to double-book myself (thank DST) and I won't be able to make the board meeting today, sorry!

We will miss you <3

In 0158, what does "An entity MUST NOT send a challenge stanza under any other circumstances." mean? knowing that "Upon receiving a triggering stanza, an entity MAY send a "challenge stanza"" is already subjective (somebody might say a stanza is concidered as triggering, somebody else not)

§3.1.2

I'm mostly curious about the usefulness of the MUST NOT

Also still §3.1.2, "The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the sender, if any.", there is always an xml:lang attribute (if not on the captcha element or message, on the stream)

Fellow board members: I'm faced with an emergency at work, and can't attend the meeting.

no worries

time

time is it

ok... :)

ralphm, are you around?

(Maybe we are not enough)

I'm at a company event all week, as mentioned last week. Sorry!

Ohh right

my bad

so no quorum

Then I will say just thanks nyco for the newsletter!

welcome, not finished though

Kev: you should work on making your statements less British and more understandable... re "I think we need to either not be introducing voting items that people effectively can’t vote in"

Summary: Instead of lawyering a way to get votes through, work on a way to maximise potential participation.

that's a general problem, if you allow me given the diversity of our community, we should all be responsible for understandable communication using a simple English form helps

It's a general problem, but from what people keep saying I'm the worst offender.

something about hithertofore

jonas’, that word made me retroactively confused about everything said in the last hour

hitherto is one of the few unhelpful words that I /don't/ use, I think.

I do try, when I remember, I just often forget.

(And I like the way I speak :( )

"Kev> Summary: Instead of lawyering a way to get votes through, work on a way to maximise potential participation.", I agree

To me what dwd says rings an alarm anyway, it means there's no appropriate process in place if we're trying to workaround bylaws.

To quote Kev, I do not disagree.

Neither me also

British and their fancy language

FWIW, it was useful that one time to have an escape hatch. What had happened was that we'd had a tie in voting for Board, and we had no method available to resolve the tie. Our solution was to use the meeting to reduce the Board positions, so the tie was irrelevant, and then by the next meeting we'd worked on a long-term fix for that problem in the bylaws.

David Cridland, Kev, maybe this needs to be brought as an agenda item for the next annual meeting? :-°

Bylaws overhaul?

Well we have identified a problem

When I tried to correct a typo..

So yeah

well, I think that is a bit strong

The process is unclear and definitely not used often enough :) ✏

In fairness, it's the kind of process we shouldn't be using opften at all.

David Cridland: why not?

Changing our bylaws?

I agree

Tbh, bylaws are quite hard to read. I'd be happy yo have a more understandable language being used

pep., legalese tho

Sure, we can get that reviewed

Bylaws /should/ be hard to change, so that you don't accidentally let something bad trough.

I disagree

With the "should be hard to change"

I personally believe that your particular changes aren't pressing enough to be classified as a problem.

These bylaws have obviously not been written for this era with all the "in writing" appearing in there

If the Secretary is willing to accept e-mails over handwritten letters as

ralphm: sure ✏

'writing', and there's an actual meeting subsequentially, that's perfectly fine.

I'm personally wondering if it's not too easy to change the bylaws.

Zash: well, the corporation == the body ofmembers. If there's a majority for a change, you can change things.

Zash: dunno about that. Maybe member quorum can be changed to more members or sth.

Majority of 1/3 does seem low

That's a valid point. I dont' remember why that number was chosen.

I'd find it more normal to require 2/3 majority on two consecutive members meetings.

Well, we're not writing the Constitution here.

ralphm: It's kinda standard for random gameing associations here.

Random non-profit organizations for any purpsoe even

I think there is a problem here that it is worth solving, and I think that problem is that it's unclear how items can be added to an agenda for a meeting, and who is eligible to vote on them.

I think that our Bylaws actually require Board to suggest changes, which then have to be approved by the membership.

I think the other concerns are secondary, really.

So before changing things you need a willing Board. If you don't currently have one, you need to follow procedures to fix that first.

But Ralph is right that only the Board can change the Bylaws.

Zash: does that give you more assurance?

(And need the members approval)

that's not at all what dwd said yesterday

And that couldn't happen e.g. during a members meeting, because of periods of notice for Board meetings.

You might find, BTW, that the "in writing" bits result from Delaware law.

deposing board is not necessarily easy

ralphm: Some, as long as Board can't do it without support from the Members

David Cridland: ah yes. So this may apply: https://delcode.delaware.gov/title6/c012a/index.shtml

Zash: it can't

Good

ralphm, Probably. Delaware Corporation law is notoriously loose - it's why so many companies are incorporated there - but it probably has various constraints.

David Cridland: particularly § 12A-107, so arguably we don't need pep.'s change

Ah, good spot.

And there are similar provisions in Dutch law, and I'm sure in most other modern jurisdictions.

pep.: I reviewed both changes, and consider them unneeded.

(and recorded that on the respective PRs)

Well, one's possibly unneeded, the other is wrong, isn't it? Having just checked the typo one myself.

proviso is just a word that means what it is supposed to

Right - I mean that changing it to provision isn't simply unneeded, it isn't the right word for the intention there.

I've done the negatives thing again, haven't I.

"provision is the wrong word"

Ok, so the typo is not a typo. Now how many members do need to say the other is unneeded for it to be unneeded

None.

They can only say so during a vote, no?

It's Board, not the members, you need to take this to.

Why

Because that's what the Bylaws require.

The Board makes changes to the bylaws, with the Members' approval.

Members can override this right?

I don't see where the Bylaws say that - which bit are you looking at?

I'm not at the moment

If so, that is missing, IMO. I don't want one person to be able to veto everything going through

Where's the veto coming from?

I don't see that bit, either.

You can initiate the removal of a board member

Or all of them.

Kev: ok I read ralphm's message above too fast

The power is ultimately still with the membership.

Removing all of them via new elections or just rm -rf board/ ?

Either can be done by the Members.

Imo bylaws would be members matters and board here only to address daily business, not block members from changing bylaws (which is what I understand with "So before changing things you need a willing Board. If you don't currently have one, you need to follow procedures to fix that first.")

Well, Board are the legal custodians of the XSF (which is a legal entity). Any change to the Bylaws needs to be legally valid, so having the Board as the keepers of such changes (with the proviso that they can't make changes the Members don't like) seems right to me.

I'm not saying that's not what it is currently

What you desperately don't want (must not have) is a subset of the Members, probably well-meaning, making some mistaken edits to the Bylaws that are in some way mistaken.

And if you remove Board from the equation that's what you get.

Now, Board could propose 'bad' changes to the Bylaws too, but they're the ones who're legally responsible for it, so at least it's on their heads.

Kev: which is why I would increase member quorum, rather than leaving this to 5 (potentially non-)members

But this isn't left to 5.

Kev, maybe that's why it's common to have two readings of changes to the bylaws here.

Zash: There's two for the XSF too, essentially. One is that the Board must approve the change, then the Members must also approve it.

Kev: ok. My original point was that I don't want board blocking changes

Also usually any (member?) usually get to propose any changes to any document.

Works I suppose

Kinda like how the govt proposes laws and parliment votes on them

Zash: Well, I don't think that Board are going to refuse to consider a change brought forward by Members (and if Board do start refusing to listen to Members, Members have a mechanism for removing them).

Kev: in any case I agree with you that the way to propose agenda items should be clarified.

could a proposed vote be something like "Fire current board. Amend bylaws to do X. Rehire current board." ? then members could just vote on that themselves?

moparisthebest: No, because the Board must make the change to the Bylaws"

If you fire the Board you need a new one before that can happen.

Which is in a way also two votes by members, first for a Board positive to the change, then for the change itself

"Fire current board. Hire Y as board providing they immediatly amend bylaws to do X. Fire Y. Rehire current board."

They can't *immediately* amend the Bylaws.

if they are all in the meeting they can't?

No.

*providing they agree with our bylaws change

I suggest, possibly unreasonably, that everyone currently proposing that we change our Bylaws in some way, goes away and reads the Bylaws first.

Can I request them in writing? 😛

When I was saying bylaws are not easy to understand..

Kev, not sure how these things work in Delaware law, but usually the members can instruct the board to do specific things.

You may request many things in writing, as stated in the Bylaws :p

I feel this discussion is what you get when software developers think legal documents are like code.

Also bylaws are just bylaws, laws override them, so even if bylaws now say members can't do anything, it's just factually not true

larma: I think we're a long way off anything that would require the Members to get into a legal battle with the Board.

I don't think there's an actual problem here and we're talking a many hypotheticals.

ralphm: I think there *is* a problem here, it's just not the one being discussed.

ralphm: ask lawyers to volunteer under a legal working group at the xsf?

Hah

pep.: To solve what?

that probably happens when approx 100% of the members are software developers :) I know I'm guilty

The problem, I think, being that it's not clear how to get something onto the Agenda, and who then votes on it :)

A legal team *wrote* this text.

I also think there is a problem, and I'm happy to retract both of my items for the one Kev is talking about

Which tbh, was mostly what was I was expecting from all this. To figure out how to do it

A good first step is: ask Board.

I'm uncomfortable with the suggestion that it's possible to interpret the Bylaws such that a single person could, in the perfect storm, vote on something on behalf of all Members.

Legal team gonna legalese

Or, if you want to bypass them, ask the Secretary.

(Which Dave's (a) reading leads to, I think)

Kev: yes, I think that notion is false.

ralphm: I think I would not want to bet anything substantial on how a legal reading would go, if it came to it. ✏

Intent is the most important thing in legal terms.

While y'all are reading the Bylaws, is there anything in there that would prevent someone from being a member without their name being public?

That is, I don't agree with Dave's (a), but I don't think it's a completely unreasonable reading, either.

IIRC this came up last Summit

Memberbot clearly lets you proxy specific *votes*, not a carte blanche to represent members in new matters.

Indeed.

Zash: I don't think so? And if required I'm sure only the secretary could be told

But I think Dave's (a) was that once you have cast your vote, you have left the meeting, and then the remaining members present could as quorum. So if only on member remained, a majority of that 1 could vote.

What I think I'd like to see Board (new, presumably) tackle is proposing a change to Bylaws simply that the items for vote at a meeting must be announced X in advance.

I don't read it that way, per my email.

Which would mean that anyone proxy voting can be represented, and all is good, with minimal change to our process or bylaws.

+1

pep., yeah, practically, only the secretary needs to know. As long as the secretary can't just make up a bunch of sock puppets and take over the world

Kev: makes sense

stpeter: hi!

Zash: we already trust the secretary with our proxy votes

Actually the laws also only require the secretary to know

§6.7 The Secretary shall have general charge of the membership records of the Corporation and shall keep, at the principal office of the Corporation, a record of the Members showing the name, address, telephone number, facsimile number and electronic mail address of each Member.

Kev: I agree

I wonder where the secretary got my phone and facsimile number from?

larma: Except that members can request those records, IIRC. (That's from memory, I haven't checked)

In practice we have never gathered that information, nor have we gathered physical address.

stpeter: Probably we should either start, or amend the Bylaws.

maybe the secretary is just extremely good at doxing people

I say amend.

Kev: yes, amend.

I think start. I don't see why every Member shouldn't be required to have a fax number.

Surprising 🤣

Kev, :)

I have to say, this conversation includes wild speculation and some unnecessarily harsh language.

stpeter, if the world was all flowers and rainbows..

At least append jokey emojis if you're not serious about some of the claims and assertions here. No one, for instance, is doxing anyone.

stpeter: quite

Doxing is a violent act, in my opinion.

(I don't even know what that means.. /me looking for his translator)

oh

The act of researching a person and expose private details, like address, phone...

I took that as a joke anyway

Kev, even if members can request that records, they cannot publish them. And given the bylaws I think it should be possible to be elected as a member without publishing your private data, which we currently require. This could even get us into problems as there is no good reason to require this data to be published

oh sorry I meant the doxing comment as a joke :)

In general, yes, we should review the bylaws to ensure that they are consistent with our existing practices (and of course Delaware law).

moparisthebest: thanks for the clarification.

We once had someone ("Solarius") who applied to be a member without providing their real name. We'd discussed this matter before.

stpeter, consider that not only Delaware law applies. As we have EU citizin members, some EU laws also apply (at least for those members)

stpeter, it's come up again when passing 345 to draft. (Which is still isn't. slack off editors.)

larma: The Board did go through a GDPR exercise at the time. So what we have now is considered reasonable by the Board (or at least the Board at that time).

EU law does not govern the operation of the Foundation's articles of incorporation and bylaws per se, of course, because the Foundation is legally domiciled in Delaware. That doesn't mean EU doesn't apply in some respects to data the Foundation gathers.

Right.

Enjoy! :)

(not?)

Some EU laws apply if the organization is actively operating in EU, and that is obviously the case.

larma: I think what Peter was saying (mansplaining because he's not here now, rather than because he can't talk for himself) was that the EU laws don't apply to the bylaws. They apply to the XSF's interaction with the EU folks.

Correct.

Yeah, but we should better make sure the bylaws don't effectively prohibit the XSF to interact with EU folks 😉

Yes.

I don't think they do, whereas our current implementation might

IANAL and I don't remember all the GDPR by heart but surely a members based organization must be able to keep a record of members

Zash, it's not about keeping records, it's about publishing them