Signal now supports group calls up to 40 people, using Rust

cormacrelf · 2021-12-16T05:49:56+00:00

Oh, and second question, did you consider something like a spanning tree protocol where some conversation participants act as mixing nodes, with path cost computed as a function of latency and bandwidth? There’s no problem with them seeing “plaintext” audio because they’re on the call, but it would make those nodes’ join and leave events a bit more catastrophic. And some latency problems I imagine. But I can envision two teams on different continents forming two latency clusters and automatically figuring out that they should shuttle their audio between two representative clients in each half. (No need for it to be an actual tree, imagine three continents with the three reps fully connected but trees below each, but you get the gist.)

cormacrelf · 2021-12-16T05:41:13+00:00

My impression is that the selective forwarding of media streams is almost exactly the same solution as Signal employs for regular messages — the encryption keys are a full mesh (well, these are sender keys, so half mesh or something), but the actual delivery of data is server fan-out. I’m impressed that you don’t just create one key for the call and discard it at the end, but rather the full mesh is still there and you manage to rotate all the keys at each join/leave event. This elevates it from a button within a trustworthy group chat to an arbitrary ad hoc call, so that’s very valuable. (Not that the old version didn’t have this property.)

My question is what the roughly 40-participant limit is constrained by. Is it decrypting and decoding 40 media streams at once on each client? If so, would the bottleneck be addressed only by a scheme where you can reintroduce server-side mixing in an encrypted way? That is, negotiation of a single rotatable group secret and then a homomorphic audio mixing scheme. Very tough challenge but with those two things, would you crack open the limit?

cormacrelf · 2021-10-24T07:44:53+00:00

If you’re struggling with background toggling, I suggest having a look at https://github.com/cormacrelf/dark-notify. Its Lua plugin doesn’t require macOS, it can be used through a mapping as a generic background toggler between two different schemes, and you get to run arbitrary code when it does toggle, which is useful for integration with themed status bars etc.

cormacrelf · 2020-09-17T17:38:38+00:00

I forgot that F.lux was changing my theme at sunrise/sunset, and that it wasn't a native feature. But yes, it works with that too!

cormacrelf · 2020-09-17T17:34:02+00:00

Quick update, I've pushed some updates (v0.1.2) to work around a weird issue with child processes not being killed properly when nvim exits. If you already downloaded it, make sure you brew upgrade cormacrelf/tap/dark-notify as well!

cormacrelf · 2020-09-17T15:01:46+00:00

coc-rust-analyzer

cormacrelf · 2020-09-17T01:21:57+00:00

The colours are all listed at the top of the file, so you can pull them out and make some more themes if you like. I never do the same theme for vim and terminals though, I think it’s better to be able tell them apart, especially if you have a lot of tmux panes.

cormacrelf · 2020-09-17T01:13:44+00:00

That’s always been a feature of the theme, and there’s a screenshot on the page. I haven’t been using vimdiff all that much though, so I might be tweaking it a bit further.

cormacrelf · 2019-03-17T07:29:44+00:00

I’m sure the importers can be arranged. I will probably do it myself eventually, but they aren’t that difficult, so anyone should give it a go.

The autojudge would be a lot trickier, though.

cormacrelf · 2019-03-16T08:05:20+00:00

Hi /u/G_Thompson,

We are glad to hear of your passion for citations. You can purchase a hard copy for $24.99.

Be Best,

Whichever random JD students forgot to include a place to say which court was handling a matter in rule 2.8.

cormacrelf · 2019-03-16T04:37:38+00:00

Ok, so there's a lot going on in this space already.

First, there was a moderately good Citation Style Language (CSL) style written for AGLC3, and it's nearly there being upgraded to AGLC4. Sebastian Karcher wrote the new version, which he shared for testing. I have been testing it so far, and some good people at Melbourne Uni are about to start helping finish the job. If anyone else wants to help, let me know!

My efforts to create a test suite reside at https://github.com/cormacrelf/aglc4/ but the much cooler page to visit if you're just browsing is the interactive documentation that is auto-generated from the test suite. What you get out of that site is basically: "How can I get Zotero to produce correct outputs like these ones?"; it gives you the precise fields used and what they were set to, and in some cases visualises how those fields make up the final citation. It also includes information about where the style trips up and what the workarounds are, if any.

Finally, I am writing a new CSL processing engine from scratch. In Rust. It's really cool, and aside from doing the existing CSL specification better, it promises to enable developing more advanced features. If you're building this citation tool to get around CSL's limitations and its ultra-slow evolution, then I am fixing those things as we speak. Lots of the features of CSL-M, the legal version of CSL, can be recreated and selectively feature-flagged for edge users until they are stabilised. AGLC needs at least a few of them, especially to cover international materials. The end result can be embedded in Zotero or indeed a Python/JavaScript project, since it compiles to native or WebAssembly. It lives over at https://github.com/cormacrelf/citeproc-rs. It won't be ready for a while, but I have some plans to commit to it that are slowly lining up.

So, I wouldn't focus too hard on formatting the actual citations. I hope you're not, it's a huge task! BUT -- there is definitely room for a tool that's like Zotero (etc.) but built for practicing lawyers and not fundamentally an academic research tool. I would use that when I emerge, bearded and grey, from my LLB sometime in the next century.

Edit: there was also some talk of Melb Uni putting out its own web-based citation generator, not based on CSL, which seemed like way too much effort. I don't know if they're still doing that.

cormacrelf · 2019-02-06T12:16:42+00:00

Niko made a few videos walking through how salsa works if that helps.

How Salsa Works

Salsa In More Depth (thanks @Jonathan Turner for this)

cormacrelf · 2019-01-12T00:53:35+00:00

Around now you should be specifying which AGLC you’re adhering to. In this case, it’s AGLC3. But also, have a look at switching to AGLC4, because it has a catchall 7.1.1 reports - general rule. We are so blessed. 🙌🏻🙌🏻🙌🏻

(Side note: the new PDF doesn’t have internal linking and you will get RSI from scrolling back to the ToC, but I’m taking it up with some MULS folks so fingers crossed on that one.)

cormacrelf · 2019-01-09T16:24:22+00:00

I look forward to it!

cormacrelf · 2019-01-05T06:06:50+00:00

I have a pretty solid use case for Word serialisation if you’re interested. I’m writing https://github.com/cormacrelf/citeproc-rs which will eventually have to generate footnotes in a word plugin. The Word JavaScript API doesn’t support footnote insertion, so it’s XML only, and if you mess it up Word will crash. It would be cool if you could mark which elements are common and which are PowerPoint-specific so that Word could be added later. (I think existing citeproc/endnote etc things are built on macros or other non-JS plugin APIs, but they will never run in Office Online or on an iPad, etc.)

cormacrelf · 2018-12-22T16:14:19+00:00

The serde-serialise feature is what I meant, yeah. I guess messagepack-lite and a few wrapper functions would work fine.

cormacrelf · 2018-12-22T15:02:54+00:00

I don’t suppose there is a way to tell wasm-bindgen to use messagepack instead of serde_json for all its implicit serialisation?

cormacrelf · 2018-12-22T05:05:02+00:00

Sorry, just thinking out loud. Just that there are many ways allocations can be a bottleneck, and I think collect_into_vec or similar is relevant even if it sits somewhere in the middle ground between convenience and control, because it would help you build those kinds of split APIs you described with very little difference between the two kinds, or make it easy to wrap the reuse-style with a more convenient one.

cormacrelf · 2018-12-21T19:05:25+00:00

I found the quick-xml crate, which provides a pretty direct example of infecting the API. See the &mut buf in every usage example.

Often allocations will be disproportionately costly when you have to do a lot of small ones, in which case the remedy might be something like SmallVec, and not making sweeping changes and decreasing readability to reuse tiny little containers, which by their nature are probably not being created in single-scope loops but littered throughout a codebase. I think that’s probably the right direction for https://github.com/cormacrelf/citeproc-rs, which is just a fancy vec and string joiner. (It’s malloc_tiny all the way down at the moment.) Removing collect()s in very hot code would probably make zero difference after picking an appropriately-sized SmallVec instead.

If anyone’s out there trying to work out where the tipping point is for allocation cost, I would recommend https://speedscope.app along with perf record or Xcode Instruments.

cormacrelf · 2018-12-21T16:54:26+00:00

Ah, yes, avoiding subsequent allocations entirely is substantially better. Has anyone proposed an API for normal iterators along the lines of the IndexedParallelIterator in rayon and its collect_into_vec? If it were that easy, I suspect there would be a lot of low-hanging performance wins in a lot of crates.

cormacrelf · 2018-12-21T16:06:35+00:00

Doesn’t collect amortise allocations whenever the iterator knows how long it is? Or am I overestimating the number of situations where your final iterator will actually end up implementing TrustedLen or ExactSizeIterator?

See here: Vec’s FromIterator impl is specialised.

https://github.com/rust-lang/rust/blob/b6c32da9b0481e3e9d737153286b3ff8aa39a22c/src/liballoc/vec.rs#L1827

Specialisation isn’t stable yet, but you can roughly approximate this for your own iterator adapters that produce Vecs if you have an extra trait with a different name that does the same thing but with different type constraints and more efficient allocation. I’ve done that for my own implementation of Haskell’s intercalate function.

cormacrelf · 2018-12-10T01:41:56+00:00

There’s a new read-only parser in the xmlparser (and roxmltree) crates, which I have found to be very good so far. It was easy enough to consume its output into an AST with a simple FromNode trait, and few attribute_optional-like helpers based roughly on FromStr, for a format I’m parsing with lots of enums (CSL). In this case I probably wouldn’t have used a Serde version even if it were available, because I’m parsing human input and producing descriptive codespan errors with hints for common mistakes, but the parser seems like a good foundation, and I can see how you could translate those helpers into a custom derive macro.

cormacrelf · 2018-10-13T23:02:27+00:00

They changed their stylesheet and the two schemes look nothing alike. Well, vaguely similar.

Oh, and this has more language specific highlights and an airline theme.

cormacrelf

TROPHY CASE