kennytv

Signed chat

This gist intends on clearing up some of the misinformation surrounding signed chat/the reporting feature Mojang has added to Minecraft 1.19.1. Here you can find both technical information as well as a general explanation of how these work.

Profile keys

After joining a server, clients now send a profile key used for verifying a message's authenticity. This key and thus the whole signing process is optional, but by default, servers enforce secure profiles for clients to send chat messages. Whenever the player sends a chat message and has a key associated, the message will be signed using their own private key, which the server then verifies using the public key sent after join. Assuming signature, timestamp, and message contents line up, the message goes through.

On the other end, clients can also require all broadcasted player messages to be signed, disregarding the ones without sender verified signatures.

Message signatures

timvisee

Falsehoods programmers believe about time

This is a compiled list of falsehoods programmers tend to believe about working with time.

Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.

Falsehoods

• There are always 24 hours in a day.
• February is always 28 days long.
• Any 24-hour period will always begin and end in the same day (or week, or month).

Diggsey

Looking into the Future

futures-rs is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.

I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.

In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.

For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.

If you're interested in learning more ab

Arnavion

A tiny crate that provides async and await macros to create futures::Futures and futures::Streams.

Code that uses these macros requires #![feature(conservative_impl_trait, generators)]

• Returning a futures::Future

   #![feature(conservative_impl_trait, generators)]
  
   #[macro_use]

jFransham

Achieving warp speed with Rust

Contents:

• Number one optimization tip: don't
• Never optimize blindly
• Don't bother optimizing one-time costs
• Improve your algorithms
• CPU architecture primer
• Keep as much as possible in cache
• Keep as much as possible in registers

chitchcock

Stevey's Google Platforms Rant

I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.

I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real