XSF Discussion - 2022-11-18

hi folks! I tried to make the build process of xmpp.org's software section a bit more informative. if you look at the "Prepare software list" and "Generate/add compliance data" sections in each build log, you'll see which package is expired, which one offers a DOAP file (I count 52 already, hooray!), and which one doesn't. also, problems with calculating compliance data become obvious this way. here is an example: https://github.com/xsf/xmpp.org/actions/runs/3494138103/jobs/5849652578

https://spacecloud.one/upload/7b02c1d5-c807-48b1-a441-9c724c511507/1dd19897-aa15-4158-9b31-a8b4ab4342ef.png

Very nice!

indeed :)

> Compliance data available, but no match for: P\u00e0d\u00e9 Say what?

THAI CHARACTER YO YING?

It's Pàdé, and probably an encoding issue in the tool chain :) I'm trying to fix that

Hehehe. Welcome to my everlasting effort to fix encoding issues in Ignite's tool chain too. Thanks for that, Dele :)

Looks pretty sweet, by the way, mr. Salat.

It's sad to see so many projects having expired. I stand by the reasoning behind us hiding them (and we successfully get rid of a lot of crud this way), but maybe we should consider not completely hiding potential value. Can we expose those expired entries behind some kind of link? Something like: "Can't find what you're looking for? Please click here for older listings, that have not been updated in a while."

would it make sense to have a "component" section in the softwares listed on xmpp.org? also, wouldn't it be nice to use the doap files to list which client/server/lib[/component?] implements a XEP in xmpp.org/extensions/xep-XXXX.html?

oh, I have very strong arguments on that. Confusingly, they are both for and against that idea. :)

erm, about Q1 or Q2? ^^

2

i'm ambivalent on 1.

on 2, damnit

typing is hard.

on 1, I do not have a strong opinion any way.

my idea for 1 is that slidge (sorry for being self-centered, but this is what I know...) could be listed as a library, but then there is no right place for slidge-signal or telegabber; a component section would be suited.

Guus: q1: I think the general consensus was to move implementations to DOAP and to display their best compliance suite value, so unmaintained ones will end up showing as "Basic Client 2006" or somesuch

Guus: yes, listing those in a separate section may be an option. and as Ge0rG says

and then maybe to display-filter based on current year(s)?

about 2, it's just a usual/recurring confusion I had while trying to do stuff "the modern way" but I guess modernxmpp.org is the answer. also some XEPs are deferred or still experimental while widely implemented so it's a bit confusing sometimes... but it's just lack of (human) resources to actually advance their state I guess

and yes, a filter box is a good idea. I'll add compliance results to each cards, so they can be spotted easily. maybe we can get rid of the renewal process after that, and list packages with a DOAP file (those with a compliance level prominently), and others less prominently

nicoco: I think those should be 5 categories: clients, servers, libraries, components, tools (we have all of those listed, but components and tools are in libraries atm)

Ge0rG: I think that you're numbering differently than nico and I are doing, but: understood.

should we worry that to much automation will cause developers to fake compliancy in order to get linked as much as possible?

I think this will happen inevitably, and we should act when it does. but less automation would lead to outdated/incorrect values instantly

> developers to fake compliancy in order to get linked as much as possible? History says this is likely to happen, as it happened even with non-automated lists.

Whether that's actually a problem worth giving much thought to might be another matter.

faking entries > expired entries ? :)

you can't prevent people from faking stuff.

but I think that people lying about their XEP compliance will be the exception, not the rule

Should we really have 5 lists. I was the one starting to add tools to libraries

Where to add components then? Servers?

one list where every entry is assigned (at least) one category?

First would prefer to have it in one list and only key that differs. then we can have it on one page with respective sections?

Would it be possible to extend Vcard4 and add Mastodon profile link in it somehow ?

https://www.rfc-editor.org/rfc/rfc6350#section-6.7.8 ?

flow, yes, good point

Zash, it's a bit more than a URL, there is no way to know if the URL is actually a Mastodon one because of the federation

Does the user or the code need to know that it is Mastodon in particular? Or, generic ActivityPub?

https://www.rfc-editor.org/rfc/rfc6350#section-5.6 allows for some x-name except https://www.rfc-editor.org/rfc/rfc6648 deprecates it

Write an RFC that adds some TYPE value for social media to the registry at https://www.iana.org/assignments/vcard-elements/vcard-elements.xhtml#parameter-values .... ?

but l10n

and i18n

Generic human-readable description of the property* would have been nice I think ✏

jonas’, oh no, now you need language tags for the properties :(

Without inventing something new and namespaced, I'd suggest `<url><uri>https://fosstodon.org/@zash</uri><type>x-activitypub</type></url>`

Mhhh 🤔

Zash, edhelas: or use the acct: URI for their webfinger

How does it look like ?

acct: if just used for webfinger so just the scheme makes it pretty unambiguous. Do webfinger lookup to know any specific things like profile url etc

acct:user@mastodon.social

acct:@user@mastodon.social no ?

no

edhelas: no

There is no leading @ in activitypub or webfinger stuff

That's just how Mastodon users type into their text box because of Twitter syntax for replies

Okay

(technically activitypub doesn't require or suggest webfinger at all, but Mastodon has made it near universal for AP users)

That didn't come from mastodon, but from ostatus iirc

I.e. gnusocial et al

raucao: it was developed by the OpenID crowd and used by OStatus, but Mastodon is who mandated it in conjunction with ActivityPub specifically

IIRC Google+ too

Mastodon used it with ostatus before was my point

Does AP define a discovery mechanism at all?

> IIRC Google+ too Huh, that's interesting! Why did they need to discover URLs for their own users?

IIRC in AP you GET some URL with Accept: application/json and see if you get JSON-LD back, or somesuch

raucao: yes, AP discovery is done on HTTP level

What does that mean? Webfinger is also just http

raucao: no, webfinger starts with acct: URI and turns it into http

AP starts with the HTTP that the webfinger can be used to discover

So that's a no

What's a no?

No discovery defined

You have to know the URLs beforehand

Discovery from what? With webfinger you need to know the acct URI beforehand also

No you don't

It's thing@domain.tld vs https://domain.tld/thing that's all

It's defined as a well-known URL. You only need to know the user address

Which can point to wherever

An end user doesn't know your full URL. Discovering it is what is called discovery in webfinger. You could also use a URL with it

K

But you have to discover inbox URLs etc for AP

Yes, those aren't in webfinger

They sure are

Webfinger just points at the AP endpoint

And then you discover anything additional from there

Ah right sry brain fart

It points to a profile actually

Mastodon uses webfinger for two reasons: to allow using @ instead of / in the address and to reuse the old OStatus remote follow protocol

But yes you would have to know the full profile URL which can be different for every server and software

It's not just a slash ✏

And it doesn't even have to be on the same domain

As the webfinger? Sure, it doesn't have to be, that's fine

I mean it's very similar to xmpp in that regard

You still need to know there user's address. The only difference is address format

Same address format

user@host

Usually you go to their webpage (at a url) to find out their webfinger address anyway

So for me I usually just cut-paste the url I have and ignore webfinger. Saves me a step ✏

I think we can agree that most users click on a name somewhere and don't know what a URL is :)

hence the "I'm @somename" problem with everyone being on centralized services

Sure, most users don't use the webfinger URI either. They click the follow button

I'm very happy people learn about user addresses that aren't email addresses now

Put `<a href="mastodon/@me">follow me on mastodon</a>` on your wobpage

(I'm working on remoteStorage and we also prescribe webfinger. But most people type their email address in connect dialogs)

People definitely use the webfinger IDs now, because that's how you mention someone on a different fedi instance

If you wanna discover non-google microblog or storage endpoint from users' gmail then you have a problem yes.

Yeah, we have half a dozen gmails get typed into our boxes labelled "jabber id" it's fun

Yes, and it's mostly a cultural problem. Like email addresses also were, or hashtags, or @usernames

Or phone numbers even

Remember people having to learn cellphone numbers?

🤣

Have I finally forgotten my ICQ number?

Mine was too long to remember. My dad had a nice short one

I spent so much energy trying to get people off other IM services and on to ICQ back in the day, rarely successfully

ICQ was my first

> Have I finally forgotten my ICQ number? never

half of it seemed to have dropped out of muscle memory

> Have I finally forgotten my ICQ number? I tried to remember mine... and I succeeded, globdammit 🤦️ and it was a 9-digit one, even

anyway, thanks for mentioning webfinger. I was recently very disappointed and headscratchy to not find some defined ap:user@server scheme. still disappointed to be required to fetch a pile of json via http 💢

mine is seven digits, but number logins have been deactivated how long ago?

very basic question incoming: how do I locally render HTML from XEPs? there sure are a lot of different scripts in this repo ^^ also, anyone ever worked on something like a markdown to XML thing for XEP? maybe with pandoc or so?

oh, tools/2xep.lua looks like what I was looking for

on a similar vein - I've wanted to do a browser extension for ages that'd work with XEPs to translate the examples into something in your own context. A lot of the work I do is testing, and I'm often translating from shakespeare to something more boring :)

nicoco: `make xep-0433.html` should do the trick and put the HTML render result into build/xep-0433.html

nicoco, 2xep.lua is markdown → xep-xml, you want tools/xep2md.sh ?

for html, just `make xep-xxxx.html && open build/xep-xxxx.html` ?

Georg: great! so not used to compiling things that I did not even notice the Makefile.

Oh, Ge0rG already said

Zash: well, both would be great actually, I'd like to propose an update, but I guess xml->md->editing->xml will induce too many diffs. I'll try it anyway, I don't have the XML-brain yet so it's really tedious to write XML directly.

thanks

just do xml->json->editing->xml :trollface:

`{"xep":"<xep><![CDATA[<html>....`

or xml->latex->xml maybe? jk I write everything in markdown since I discovered my lord and savior pandoc. all hail pandoc!

I doubt the xep format can be properly represented in markdown or latex since it has all kinds of custom stuff

nicoco, make html

pandoc is love, pandoc is life

(such as entity references to other xeps)

Zash, `make build/xep-xxxx.html`, IIRC

singpolyma: there is a pandoc filter written by Zash that seems to cover just that ^^

Ah. So custom markdown

The pandoc filter should handle basic structure, metadata, but not stuff like entity references

maybe time to have some fun with pandoc and lua then! ✏

That may reach the limits of what markdown can do

jonas’: both paths work

fancy

Zash: lua xep renderer in koreader when? :D

That's why I had xep→markdown, so I could pandoc it into .epub :)

Can't pandoc read HTML and make epub from that? Especially since epub is just HTML in a zip

reminds me that the standard document format for RFCs still is US Letter.

Ge0rG, I thought they went markdown-on-github now?

Zash: did they? are they going to markdown all the existing RFCs, too?

unlikely, but most new things look like https://github.com/mlswg/mls-federation

I actually like markdown for redacting stuff... is that a bad thing?

not at all, markdown is a nice trade-off for 90% of tech docs

if you have a dialect that supports tables and diagrams, you are probably at 95%

I wrote my phd thesis in markdown (+pandoc +some awful scripts to make it fit the latex template the uni wanted me to use). so I think it can cover anything 🙂 ✏

I wrote my phd in LaTeX.

nicoco: well, it depends what you wrote your phd about.

to me, it's just too much useless markup things, be it latex or html. the promise of separating content from formatting doesn't hold. whereas with basic markup languages, you can actually focus on the content. but as usual, whatever works for whoever is fine 😉 ✏

to me, it's just too much ~useless~ distracting markup things, be it latex or html. the promise of separating content from formatting doesn't hold. whereas with basic markup languages, you can actually focus on the content. but as usual, whatever works for whoever is fine 😉 ✏

What I've done is write early drafts in markdown, then turn to xep-xml for submission and future editing... if I ever got that far

yeah, I wouldn't do another document in TeX today, I'm too old for this shit

that said, ietf's markdown to xml tooling is pretty good and I see many I-D being written that way (rfc4880bis for an recent example)

I wonder if we couldn't do something similar for XEPs

that is, keep the existing XML infrastructure and tooling

but be able to feed it with something markdownish

yes please

would also help the editor a lot

(but not as much as other things in the ~"Editor Tooling" label ;-))

And I'd really would love if XEPs had a meta layer with rationale, design considerations, and further secondary information. the layer wouldn't show by default, but if you ever wondered why something is designed the way it is, then you may be able to look it up

isn't Design Considerations even a part of the template nowadays?

it is, but ignore that for now, it's misleading for my point :)

essentially technical documentation consists of specifications (how you do things) and rationale/motoviation (why you do things)

if both things are immediatly present, then first-time implementors can be overwhelmed by the provided information

ah

yeah that makes sense kindof

so my idea is to have a "space" for secondary things that are not directly required to implement what is documented

of course, this "space" should be within the document itself, it just should be rendered/presented differently (e.g., hidden, with a visible hint that something is hidden there, by default)

Guus, fixed Pàdé ;)

ftr, it never was anything Thai because \u is followed only by 4 digits :P (i.e., 00e0, not 00e0d)

mjk: bummer! thanks for pointing that out, I totally fell for it ✏

another reminder here as well for our current board&council elections. When you are a member and have not voted yet then please take some time and do so. Thanks

Ge0rG: happens to the best of us :D

This is the draft for the next release covering November 2022. https://github.com/xsf/xmpp.org/pull/1209

If you support, please put your nick, we would like name our contributors. But feel free to stay anonymous of course