str4d

5 ms·

1.
by str4d 1y ago
> The XDG specification has been around for 22 years. Indeed! > It has real benefits for users. I once believed this! > It's trivial to implement. Nope! I ranted about this a while back ( https://bsky.app/profil
2.
by str4d 2y ago
> The firehose is all public data going into the network right? It's the "main subset" of the public data, being "events on the network": for the Bluesky app that's posts, reposts, replies, likes, etc. Most
3.
by str4d 2y ago
> > If you want large scale social networks, you need to work with a large scale of data. Since federated open queries aren’t feasible, you need big machines. > Thats just simply not true. > [snip] > This is why ActivityPub h
4.
by str4d 2y ago
Additionally, a user _can_ root their identity in DNS if they want, by using did:web instead of did:plc [0]. The main Bluesky client doesn't expose this (presumably because did:web cannot provide a mechanism for automatic migration bet
5.
by str4d 2y ago
For a lower-friction firehose experience, you can use Jetstream [0] (by one of the Bluesky devs) which supports subscribing to specific Collection NSIDs and user repositories, and converts records to JSON for you. There's a public inst
6.
by str4d 2y ago
For non-Bluesky apps built in ATProto, in addition to White Wind (blogging), there is also Smoke Signal (events, only Lexicons are open source currently AFAICT) [0], and Frontpage (link aggregation) [1]. [0]: https://github.com&#
7.
by str4d 2y ago
There are a few more details about the reason they didn't use JSON-LD in Paul's blog post [0]. [0]: https://www.pfrazee.com/blog/why-not-rdf
8.
by str4d 3y ago
> But I’m still wondering how one would aggregate reactions. It seems it would not be enough just to have a PDS, but also to run an Indexer/Relay, which indexes other peoples PDS. And not just the PDSs of the people you are followin
9.
by str4d 3y ago
A useful way to think about it is that the PDS is a "user agent" - they act on behalf of the user, and with the user's implicit trust. This is much the same way that a user trusts webserver software (and the VPS running it) t
10.
by str4d 3y ago
> The indexer is only necessary because the user ids do not remain static on the system. Instead there is some weird cryptographic reshuffling going on where DID:PLC starts as a substring of a hash and then because of 'key rotation&
11.
by str4d 4y ago
> There is a sub-curve (Ristretto) which is of prime order which can be used on top of curve25519. I'm sure you are aware of this and are just abbreviating, but I think it's important to clarify this for other readers: Ristrett
12.
by str4d 4y ago
I was briefly _very_ confused when I saw the news.
13.
by str4d 4y ago
> But if I recall, it seems that the age key file itself is 128 bits! Thus in the symmetric mode, Age provides only 128 bits of security. This is substandard, and in particular secure only until 2035 or so. This is not the case. To meet
14.
by str4d 4y ago
Ooh, nice! Having a Kotlin-native implementation will be a significant UX improvement over e.g. using my Rust age implementation via FFI / JNI behind a wrapper. It also reminds me (again) of the cross-language plugin question. The CLI
15.
by str4d 4y ago
> Tornado Cash is a service, _run by an individual_ who was warned to cease serving sanctioned entities, and failed to do so. This is false. The (vast majority of the) Tornado Cash contracts were either deployed to Ethereum as immutable
16.
by str4d 4y ago
> A good feature of PIV applet of Yubikey 5 is that it stores 24 keys. Note that not all 24 of those keys are suitable for age usage. The 4 main keys have specific usage definitions in the PIV specification that mean hardware tokens alte
17.
by str4d 4y ago
Yep! Plugins themselves are ephemeral - all of their runtime state is provided by the age client - but when the plugin binary is invoked by the age client, it can then connect to (or start) the long-lived agent process and act as a proxy to
18.
by str4d 4y ago
> and also a mobile app that can do this (right now I use PasswordStore on Android, which communicates with OpenKeyChain which is basically GPG for Android with a nice shell around it). So I use the Yubikey over NFC there (though USB is
19.
by str4d 5y ago
The change in hash function did also result in speed improvements. Quoting the commit messages: Change to BLAKE2s: > This also has the advantage of supplying 16 bytes at a time rather than SHA1's 10 bytes, which, in addition to havi
20.
by str4d 5y ago
My answer to that is "maintainability". The more flexibility and moving parts we add to the RNG, the more things that can break. The delta from "one hash function" to "two hash functions" would involve not just
21.
by str4d 5y ago
The same thing happens with age-plugin-yubikey. You can only generate identities on the device (so you never have access to the private key), and the YubiKey needs to be plugged in and available in order to decrypt, as the core asymmetric d
22.
by str4d 5y ago
A few people have been experimenting with OS integration (e.g. Windows context menu), but IDK how far along those experiments are. I've been experimenting with a web-based UI [0] for my Rust implementation of age, because I really want
23.
by str4d 5y ago
> o It's odd that -e (encrypt) can recognize an age-keygen file, but -d (decrypt) errors out with: > > age: error: failed to parse recipient file "person.pub": "person.pub": malformed recipient at line 1 I&
24.
by str4d 5y ago
> For some reason, I was under the impression age itself had some logic for keys.txt files. An early version of the draft spec did include a default keys.txt path, and I implemented it in rage. However, during the beta phase discussions
25.
by str4d 6y ago
We've just finished our own updates to the draft, and are currently getting some feedback on it off-list before we publish the next version.
26.
by str4d 7y ago
Answering what I can. Where something is an implementation detail, I'm referring to rage (which I'm obviously more familiar with). 1. rage tests arguments for validity as filepaths, and uses the file preferentially over treating t
27.
by str4d 7y ago
Yes. age encrypts large files in 64 kiB chunks with 16 bytes of overhead per chunk, which strikes a balance between file size overhead and performance (particularly when seeking).
28.
I2P Summer Dev 2017: Performance Improvements(geti2p.net)
2 points by str4d 9y ago|0 comments
29.
by str4d 9y ago
> ZCash is pretty explicit about the difference between shielded and transparent addresses.... This is an important point. Having two very distinct addresses (different lengths, different prefixes, different RPC APIs) makes it very obvio