As already cited at the GSoC's proposal, the Media Server would use pubsub capabilities to give/deny access a channel's media.Although the concept is quite simple, and the necessary packets to trade such information between a client and a pubsub server, the biggest challenge was adapt the Smack API to the particularities from the buddycloud's XEP. The work was a lot easier because in the last year GSoC, another buddycloud's student (Abmar Barros) had to implement similar functionality into his project, also using Smack.So, to verify if an user like "rodrigo@buddycloud.org" can POST a media into "private@topics.buddycloug.org" all that the Media Server does is retrieve the channel's affiliations, and check if "rodrigo@buddycloud.org" has post capabilities:<iq from="mediaserver@buddycloud.org/Client" id="Eq5j2-2" to="channels.buddycloud.org" type="get"> <pubsub xmlns="http://jabber.org/protocol/pubsub#owner"> <affiliations node="/user/private@buddycloud.org/posts"> </affiliations></pubsub> </iq>RESPONSE:<iq from="channels.buddycloud.org" id="Eq5j2-2" to="mediaserver@buddycloud.org/Client" type="result"> <pubsub xmlns="http://jabber.org/protocol/pubsub#owner"> <affiliations xmlns="http://jabber.org/protocol/pubsub#owner"> <...> <affiliation jid="rodrigo@buddycloud.org" affiliation="publisher"/> </affiliations> <set xmlns="http://jabber.org/protocol/rsm"> <first index="0"> user1@buddycloud.org </first> <last> user5@buddycloud.org </last> <count> 5 </count> </set> </pubsub></iq>What are the next steps?- Fist I'd like to deploy a toy client to demonstrate some of the Media Server functionality;- After that, the next step is the implementation of the XEP-0070 and documentation. XEP-0070 is a known specification of how verify HTTP requests via XMPP. It has basically 8 steps.In the Media Server, when a HTTP request arrives, the HTTP side forwards the request to a AuthVerifier class, this class has control over an XMPP component, to send and receive packets in a synchronous way, via a SyncReplySend util class. Once the AuthVerifier class receives the request, it "asks" if the client has sent it, if yes, the request is authorized, if not, the HTTP side returns a 403 error.Here is the sequence diagram:To send its credentials, the client has two options:Via HTTP auth: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Via URL: /media/test@topics.buddycloud.org?auth=QWxhZGRpbjpvcGVuIHNlc2FtZQ==In both ways, the client's JID and transaction id, are separated by a ; and are base 64 encoded.This week, we hope to do the first deploy, to finally see the Media Server running in a production environment! Last week I've faced some problems due to URL confusion, but, it was easily fixed changing a little the approach that I was taking in the resources implementation.In resume, this is what was implemented this week:All Media Server API methods without any kind of authentication. In this way, the whole defined actions (upload, update, download and delete) are working (in a very naive way, but still...);Simple tests just to verify if everything is working in a minimum condition;Documentation improvement at buddycloud's wiki; A test suite, where we can run all test cases developed so far.I also started the implementation of the other main Media Server feature, the XMPP component. It will be responsible to communicate with the buddycloud server and ask about users permissions based on pub-sub. I'm expecting a lot of tricky coding challenges in this phase :-DOther interesting information is about the authentication process that I'm planning to use for the Media Server: http://xmpp.org/extensions/xep-0070.htmlIt is a well defined XEP about how to authenticate HTTP requests via XMPP. Denis, the other buddycloud's GSoC student, has started a very interesting discussion about how would