We are trying out Jitsi as an open source conferencing app to replace various proprietary (ugh) conferencing softwares we have used. It has always felt to me to be a bit of a last frontier… happily, though, initial tests are awesome. Video and audio quality is way better than, for example, Google Hangouts. Below are screenshots from a 6-way call this morning between San Francisco, France, the UK, Kenya (via Android App), and Athens (x2). Quality looks great!
Month: August 2017
Surfn
My buddy from NZ, Pete, dropped in on his way home to Auckland after buying parts for his car in the US. Took him surfing 🙂
The big 4
I’ve been in the business of trying to work out how to get Publishing (capital ‘P’) into the web. From the start, there have been some ‘big ticket’ items that have needed to be solved. Some are more urgent than others, but by and large we are cracking these nuts one by one. I have considered for a long time the big 4 to be:
- MS Word to HTML conversion
- an open source web-based word processor
- paginated output via the browser to print-ready copy
- in-browser designer
1,2 an 3 are the ‘now’ critical items, number 4 is necessary but a little further down the line. Thankfully, at Coko we are solving these first 3 problems. To solve (1) we are building XSweet, a comprehensive (open source) XSLT conversion suite for converting MS Word to HTML. We are also building Wax to solve (2), Wax is an open source web based word processor based on the Substance.io libs. And for (3) we are using Vivliostyle for in-browser rendering. Number 4) is still on the cards.
Interestingly, the pagination technology (3) might need re-evaluating since pagination will eventually be required for the editor and the in-browser designer.
While pagination inside a web-based processor is not critical for publishers, it is critical for authors and small offices etc and if we are going to get publishers to use a web-based word processor then it would be better that they share infrastructure rather than sit on their own island of technology ie. eventually we need authors to use these tools too. By sharing infrastructure I don’t mean they need to use exactly the same tools, they just need to use compatible tools. So, eventually, we need to migrate authors into the web. It is not critical now, but over time, as the workflow for authors and publishers inevitably becomes more integrated, it will turn out to be necessary.
For in-browser design we need pagination support also so we can work off a single source for the content and then design in the browser to output to the various formats publishers need. Think Gimp or InDesign in the browser. It’s not as far away as it might sound, but to do this we need to be able to paginate inside the browser and have that update with live style changes to CSS.
So far, we are solving the big ticket issues 1-3, but for the next stage of changes we may need to change the tools we use for pagination so we can live-update content and styles and reflow in an editor and in-browser designer. That may mean we to start looking for a different pagination solution.
When a Code of Conduct is too much for some poor souls
Interesting to see this:
https://github.com/nodejs/node/issues/15011
It is a discussion in the Node issues in Github about their Code of Conduct. One developer, with the handle ‘binoculars’, also known as Barrett Harber, is a developer from the Center of Open Science and objecting to the idea of Codes of Conduct. To quote him:
I think the concept of having and effectively enforcing a Code of Conduct is fundamentally flawed…I think you’re alienating a much larger portion of your potential and current contributor base by handing over control to the wrong-think police…Obviously, this is not avoiding conflict. It’s creating conflict. Case in point, this conversation. We wouldn’t be having it if it didn’t create conflict.
and the following two bald statements which are absolute doozies:
I’m not concerned with people’s feelings….
…and…
There’s no definition of harassment.
jeeez……it is one of those amazing moments when the speaker doesn’t realise that what they are trying to say is, as the words come out of their mouth, making exactly the opposite point to everyone in the room.
Although this person seems to have a problem with CoCs in general, the critique is directly pitched at the Node Code of Conduct which is particularly hard to understand given that the Node CoC is pretty light, easy to understand, and (I would say) rather standard and non-controversial.
The conversation is blossoming a little around the net including here.
Media De-(r)evolution
My idea of a good day in. Despite, or maybe because of, living in Silicon Valley (San Francisco is really part of SV these days), I think my media diet is devolving.
Going where your people are
Recently, I have been involved in some discussions around what tools to choose for open communities. This came up with regard to the Open Source Alliance for Open Scholarship (links to the new website coming soon!).
One argument that always comes up with these kinds of discussions, and I have been involved in many, is that we should use platform X because ‘thats where the people are’. Because open source has lost in the platform game (but its not too late) this argument almost always points to a closed source platform eg. github, twitter, slack etc
‘Going where the people are’ feels intuitively like a good idea. You want your project to succeed, go where the people are. Hard to argue against that. But argue against that we must, and I’ve started to think a little about how to counter this position better because sometimes, when people get stuck on this argument, there is no budging them.
One thing I have experienced recently that has fed a counter argument is the growing community around Coko. We use Mattermost and Gitlab as our primary web spaces for community and collaboration. What I notice with our gitlab, for example, is that when you open it up in the browser it looks like Coko. It looks like a home for a variety of connected and interesting projects that all revolve around Coko’s mission to reshape publishing. It is my hope that this will grow to be even more true over time. If that proves to be the case, then this gitlab instance will be a home (possibly one of many) for a certain approach and certain kind of thinking about how to change publishing. And that there is incredibly valuable because it speaks to the need for your community tools to surface and reflect your communities activities and values.
That’s not so easy to do in github. Go to a github org space and it looks like every other github org space. It looks dull. It reflects the identity of github and not of your community. This doesn’t just come down to theming, but it comes down to more subtle nuances such as with gitlab (or similar open source solution), the space is committed only to the things your community is doing. Things that are not connected are not a click away. From a community members point of view its a space dedicated to them. In this day I believe this is increasingly more unusual, important, and appreciated.
Consequently, I use the argument that developing community identity is more important than ‘going where the people are’. Don’t create a space ‘where the people are’, create a space where your people can go.
Setting up Jitsi, Letsencrypt cert, and desktop sharing
Ok..Jitsi initial install is easy. Working out letsencrypt is soso documented but also easy, working out how to get desktop sharing working is barely documented.
Installing Jitsi-meet
Basically…do this to get Jitsi working:
https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md
It works as advertised for Ubuntu. Except, don’t use the stable sources. We couldn’t get them to work with conferences – we could only get 1 person in a meeting which…er… isn’t a meeting! So, instead use the unstable sources, which means don’t use this:
echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list
Use this:
echo 'deb https://download.jitsi.org unstable/' >> /etc/apt/sources.list.d/jitsi-unstable.list
Then follow the rest of the docs.
Not mentioned in the rest of the docs is this….you need to set up several sub-domains, namely:
conference.[your jitsi domain]
auth.[your jitsi domain]
focus.[your jitsi domain]
jitsi-videobridge.[your jitsi domain]
Make sure that if your Jitsi-meet is already using a subdomain (eg. jitsi.mydomain.com) that you add the above subdomains on top of that eg conference.jitsi.mydomain.com not conference.jitsi.com
Now…you need to change a few things. Open the file located at /etc/prosody/conf.d/[YOUR JITSI DOMAIN].cfg.lua, it should look something like this:
Component "jitsi-videobridge.[YOUR JITSI DOMAIN]" component_secret = "sjhfss09" VirtualHost "auth.[YOUR JITSI DOMAIN]" authentication = "internal_plain" Component "focus.[YOUR JITSI DOMAIN]" component_secret = "Hjusk78is"
Change both secrets to a random string of the same length. The copy the first one to this file /etc/jitsi/videobridge/config where and uncomment the secret, eg:
# sets the shared secret used to authenticate to the XMPP server #JVB_SECRET=e355kYFm JVB_SECRET=sjhfss09
Do the same for the second secret by adding it to this file /etc/jitsi/jicofo/config, eg:
# sets the secret used to authenticate as an XMPP component #JICOFO_SECRET=Ifc7gffV JICOFO_SECRET=Hjusk78is
Thanks to Juan Gutierrez for working out the above changes to the files.
Letsencrypt
Also easy, except it doesn’t say anywhere how to do it. There is a nice script for it which is already present but you need to find it. On Ubuntu you can find it in /usr/share/jitsi-meet/scripts/
So to get it running do this (as root or using sudo):
cd /usr/share/jitsi-meet/scripts/ ./install-letsencrypt-cert.sh
The script should just ask you for a valid email address. Follow the instructions and it ‘just works’. You*may* need to restart jitsi to do that try this:
/etc/init.d/jitsi-videobridge start
Then navigate to your domain prefixed by https and it should work.
Desktop Sharing
Ha..just when you thought it was so, so, easy! It’s actually pretty easy but it’s not well documented. Essentially you have to install an extension in your browser that allows desktop sharing permissions. However this is domain specific so you have to download the extension and configure it, then compile it and then load it into your extensions. This is true for Firefox and Chrome/Chromium. I haven’t tried for Firefox but the following works for Chrom(e)ium.
Visit this page – https://github.com/jitsi/jidesha – and clone the repo or download it as a zip.
Next, with your fav text editor open the file in the ‘chrome’ directory called manifest.json, it looks like this:
{ "manifest_version": 2, "name": "Jitsi Desktop Streamer", "description": "A simple extension that allows you to stream your desktop into meetings with Jitsi Meet and Jitsi Videobridge.", "version": "0.1.6", "minimum_chrome_version": "34", "icons": { "16": "jitsi-logo-16x16.png", "48": "jitsi-logo-48x48.png", "128": "jitsi-logo-128x128.png" }, "background": { "scripts": [ "background.js" ], "persistent": true }, "permissions": [ "desktopCapture" ], "externally_connectable": { "matches": [ "*://meet.jit.si/*" ] } }
You want to edit the last line:
"*://meet.jit.si/*"
to reflect the domain of your jitsi install eg
"*://jitsi.myserver.org/*"
or whatever… don’t put in http or https or anything, just replace the domain information.
Now, you need to compile that extension. Follow these steps:
- If you open up your chrome browser go to (in the location bar) chrome://extensions
- check the box ‘developer mode’ if it is not already checked
- you will see a button ‘pack extension’ appear at the top, click this
- click the button next to ‘extension root directory’
- browser to and select he ‘chrome’ directory where you have that manifest.json file
- click ‘open’
- click ‘pack extension’
A new file ‘chrome.crx’ will appear.
Now you need to load that into your extensions, to do that you need to drag the chrome.crx file to the extensions page open in your browser. It will then just appear, by default it is enabled.
Now…you are almost there…you now have to go to your server and make a few changes. These all happen in one file, the jitsi meet config file. Open the file ‘/etc/jitsi/meet/[YOUR JITSI DOMAIN]-config.js’ with your fav text editor.
You need to change these lines:
// The ID of the jidesha extension for Chrome. desktopSharingChromeExtId: 'put your Chrome extension ID here', // Whether desktop sharing should be disabled on Chrome. desktopSharingChromeDisabled: false, // The media sources to use when using screen sharing with the Chrome // extension.
By default, there will be no chrome extension ID and sharing is default turned off. Make sure desktopSharingChromeDisabled is set to false, and put your chrome extension ID in between single quotes after desktopSharingChromeExtId.
But… I hear you say…. what is my chrome extension ID? good question… to get this, go back to your browser and in the chrome://extensions you will see an id listed next to your jitsi-meeting extension. It will be a long string of numbers and letters next to the simple text ‘ID:’
Copy and paste that into the config between single quotes, no spaces and exclude the ‘ID:’ bit. Save and exit the config file. You shouldn’t have to restart Jitsi but if you feel like playing it safe restart as per above.
Navigate to your jitsi meeting and it should work under https, show the desktop sharing icon, and enable desktop sharing! Good luck! I’ll be testing out our install in the next weeks and will post here. Oh…if you wish to replace the default jitsi watermark on the top right then replace the file /usr/share/jitsi-meet/images/watermark.png with a transparent png.
(if anyone would like to walk me through how to do the same for Firefox I’d be grateful and I will also publish that info here.).
Update: Sept 3. Juan worked out how to get the extension in the chrome store. Was easy apparently but cost $25USD.
Now if you try our Jitsi and need to screenshare, then clicking on the screenshare icons redirects you to the above Coko plugin in the Chrome store.
If you found this post useful, repay it by taking the time to document a tricky issue you worked through so others can benefit from what you learned! (I’m forever grateful for the amazing stuff I’ve found online in some random blog somewhere that have helped me out of seemingly unique tech gotchas!).
Self hosted open source video conferencing
I have tried various open source video conferencing apps. Actually, as it happens my first introduction to open source was through streaming back in the day. Since WebRTC came on the scene I have been excited by the possibility of open source web-based video conferencing. However, the promise seemed to take a while to deliver. I tried many products, the most sophisticated and promising being, for a while, BigBlueButton. But BBB, and other softwares, just seemed so clunky and hard to install, ugly UI etc. We installed and ran BBB for Coko but no one really wants to use it and we had bandwidth issues etc. Sorry to say it, but open source has been lagging behind the closed source world with regard to video conferencing.
I have been keeping my eye on Jitsi for some time. It looks pretty good. But I was caught up with my legacy understanding of such systems and it took a while, also, for Jitsi to evolve. I tried out their demo for a few meetings but it had some lag issues. Of course, trying out a demo ‘for real’ is a bit dumb and I should not have expected anything like you want in a real world production environment. But… I was a little deterred. I also assumed it would be hard to install.
Finally, this weekend I thought I would give it a go…so I started up a digitalocean droplet (a server) – which costs $20 a month and took about 2 mins to get going. I then followed these instructions – https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md. I had a Ubuntu install at digitalocean so followed those steps. But I expected complications…the install mentions it relies on jitsei-videobridge and I thought… I bet this doesn’t work…I’ll have to install some mad java app or something…What do you know…within 5 mins I had a working version of Jitsi-meet! amazing! The process worked as described, basically 3 commands and it was running.
If it works for Coko it is also very interesting because Jitsi on the front end is all JavaScript and there seem to be some react components…which means we could integrate into xpub/editoria (publishing systems) etc…
We will try it out in the next weeks. Expect more info soon!
What I’m listening to now…
Currently listening to Hearing Music by Joanna Brouk. Super crazy beautiful. Sparse, drifting tones – synth, flute, piano, field recordings. She is an American composer that died earlier this year. Hearing Music was released in 2016 as a compilation of some of her works previously released on cassette tape. Just amazing.
Also listening to Tower of Silence by Roberto Musci.
Also a compilation of hard-to-find earlier releases. Sometimes cacophonous, but mostly eerie and soothing at the same time. A mix of field recordings and almost every instrument you can think of from water drums to French horn and synth. Also fantastic.
Yep, its a brief brief
Following up an earlier post I made about the Collabra journal brief, here is the updated version with mocks.
Mocks by the talented Julien Taquet. You can follow xpub development here https://gitlab.coko.foundation/xpub/xpub and Design Briefs and issues are all contained here https://gitlab.coko.foundation/xpub/xpub/issues.
If you want to learn more about xpub or wish to be part of the xpub effort then join us in the Coko chat!
We are working on the above brief, but the second brief is already posted to the repo above.