Hello,

this week I've had to fix the way jid are used for file transfer.

To explain you the problem, I need to explain you how communication is done in XMPP (*). To be brief, when an entity (with jid louise@example.net) want to access a component (with jid files.example.net), it sends a "stanza" which is an XML element. There are 3 kinds of stanza (presence, message, and iq).
In our case we use iq stanza, so Louise sends something like:

<iqfrom="louise@example.net"to="files.example.net"type="set">
  […]
</iq>

and the component answers with something like this:

<iqfrom="files.example.net"to="louise@example.net"type="result">
  […]
</iq>

Last week I've explained how I've used the local part in components to access files from somebody else. So far, when creating a stanza, I was using the jid we are connecting with in the from attribute (i.e. where we set the sender of the message).

This is working well with clients, or components if you don't use local part, but when somebody was accessing files from pierre@files.example.net, the jid used by the component is files.example.net, a different one, so this was not working anymore.

To fix that, I've simply had to change the code to use the jid used to contact the components (i.e. the one in the to attribute of the original request) instead.

I've also fixed a MAM (Message Archive Management, XEP-0313) bug where the same messages were requested again on next start up under certain conditions.

Finally, I've completed a generic invitation mechanism to notify somebody when an event or photo album is available. When the invitation is received, the data needed to retrieve the thing is saved in a private "list of interest", which is a pubsub node. With that I can now diplay in Libervia the available photo albums as you can see in the screen capture below.

We are nearly there, I still have to complete the guest page (page for people without XMPP account), so they can see events or photo albums, and I can launch the beta. It's a matter of days now.

Thanks for reading, as always feedbacks are welcome.

(*) to learn more about XMPP, you can check my series of articles "Let's talk XMPP". It's originally written in French, and only 4 articles on 10 are translated, help would be welcomed to translate the other ones.

Hello,

this week I've had little time to work on SàT : thanks to the extended easter week-end, I've had a break.

I did manage to work a bit on the file sharing service, still focusing on the photo album. As I've explained last week, file sharing can be used directly from device to device (e.g. retrieving pictures taken on a mobile phone from desktop computer), or with a server-side service.

XMPP allows to create "components" which can be seen as generic plugins to create services on the server (generic in the way that it's not tied to a specific server implementation, but can be used with anyone implementing XEP-0114). Starting with the incoming v0.7, SàT can be used as a component, and file sharing is the first one.

Until now, it was only used to store personal data, so the files could be accessed with the jid of the component. For instance, if your server is example.net your file sharing component may have the jid files.example.net. To access photo albums, we need the path of the album (e.g. /photos/week-end) which is set in the node attribute in XEP-0329, so you can request files.example.net to retrieve your files (i.e. photo album) from /photos/week-end.
Problem: if Louise is connected to files.example.net and wants to access /photos/week-end, she will get her own album. How to do if she wants to access the one of Pierre?

That's were the local part is used, i.e. the part before the @ in a jid. The files.example.net component will receive all traffic sent to any jid finishing with @files.example.net. So when Louise wants to access Pierre files, she can use pierre@files.example.net instead of just the domain name. That's what I've implemented this week. By using just pierre, the component will associate this with its own server (i.e. example.net), and will look for files from pierre@example.net (and check which ones Louise can access).

But what for people with an account outside of example.net, for instance what if file sharing service allows nestor@example.org to store files? Louise can't request nestor@files.example.net because it would get the files of nestor@example.net (note the .net insteaf of .org , it's a different user). To allow to retrieve the files of an external account, we should be able to use a full jid in the request, but it's forbidden to use @ in local part of the jid.

That's where XEP-0106 is used, it allows to escape a jid to do exactly that. I've implemented that so Louise can request nestor\40example.org@files.example.net to retrieve files from nestor@example.org. Don't worry for the complicated address, the end-user should not have to type it herself.

Last but not least, I have also fixed the margin issue with paragraphs and added missing Atom feeds links, it should hopefully be more confortable to read this blog.

To summarize, during this short week I've implemented a way to retrieve files from an other user in file sharing component, I've implemented XEP-0106, I've fixed a small CSS issue on the blog and I've added missing links for Atom feed.

Hello everybody,

this is the time for a second progress report.

After the implementation of the button for translations, I've updated the French version of Libervia, and of the new website I'm currently working on (which is not yet online). For now this is done locally using tools like Gtranslator or Poedit, I plan to install at some point a web app like Weblate or Pootle and if possible to integrate is with SàT/XMPP (at least for authentication) to make contributions easier.

Beside that I've mainly been working on photos album, I want to be able to use it with 0.7.
For a bit of background, photo album is a specialized view of file sharing. I've evaluated two XEP (XMPP Extension Protocol) for that:

• File Repository and Sharing (XEP-0214) which is based on Pubsub and Collections Nodes (XEP-0248)
• File Information Sharing (XEP-0329) which is a simple way to share a repository

File sharing is usable either with direct sharing of a repository from a device (e.g. photos from a mobile phone), or with a server component which host files.

I've chosed the second one (File Information Sharing) for now because the Pubsub one is based on Collections which is, in my opinion, currently not usable: permissions from collection nodes are overwritting ones of leaf nodes, and as a result a private node can be accidentaly opened. This needs to be addressed, it's not the first time I discard pubsub collections because of that, I'll try to propose changes to standard after the 0.7 release.

The other reason I've chosen "File Information Sharing" (FIS) is that the Pubsub one handles mirrors and versions, which I feeled overcomplicated at the time. With FIS, I could make an implementation quickly, and I have a working UI now, which is already quite usable (see this blog post to see how it looks like).

But when I'm using the component, I have no way to change access (everything is managed, there is just no interface to change it), so when I put a file on the file sharing component, it stays private for now, not ideal when you want to share a photo album.

So I've worked on a quick way to do it, using ad-hoc commands: one to change file/directory permissions, and one to delete files. It's nearly finished and will be the last thing before starting beta phase.

That said, Pubsub has already everything needed to manage access and subscriptions (to know when new files/photos are available), so I plan to re-evaluate XEP-0214 at a later point, and if I still find it ill-adapted, maybe propose an other option.

I've also noticed a couple of CSS issues on the blog engine (mainly some padding around paragraph would make it easier to read), and I've been noticed that link to Atom feed is missing on the blog. I was planning to fix that this week but could not find the time (I'm working on SàT on my free time). So I hope to do this in the next few days.

That's it for this week. I'm looking forward to start debugging phase, and then finally release.