alexland

I haven't used Atuin (though I think I might give it a try), but maybe you could use the atuin history list command and pipe that into something like fzf or ripgrep to get case insensitive search?

That's not really the protocol's job though. We use HTTP as the protocol for APIs on the web, but HTTP does not require any specific endpoints -- that's up to the application itself. Ultimately I think this is a pain point caused by the relative immaturity of the ActivityPub ecosystem, and over time I suspect the way that services define their APIs will become more uniform (likely with the help of libraries/interfaces that define common functionality or help bridge the gap between different implementations). In the meantime it's pretty rough going though, and we'll see if some big players joining the space (Meta is rumored to be working on a Twitter competitor using ActivityPub) help define de-facto standards to make it easier.

I'm not an expert, but based on my understanding the Communities tab (as well as things like your user profile) are special to Lemmy, and stored on a given Lemmy instance. ActivityPub basically provides a shared language for how various services/clients can ask for and send each other data (posts, comments etc) in a totally agnostic format. Lemmy renders this data as posts and comments, but Mastodon renders them as toots and so forth. And that's an oversimplification, because there's no guarantee that two pieces of software (Lemmy and Mastodon in this example) will operate with the same ActivityPub types, so the way content is displayed is inconsistent or possibly entirely incompatible. If you want to create a generic Fediverse reader, you would need to keep an up-to-date representation of every type that every common ActivityPub software uses for its content, which could work but I imagine would be quite tedious and prone to breaking. That being said, I was imagining something like this existing myself, and I suspect over time as different types become common "building blocks" for different types of social networks this will be more solidified and straightforward.

To your mention of content not being accessible from everywhere, it sounds like maybe you're expecting a centralized directory of information, but that's the big difference with true decentralization/federation. No single Lemmy instance know of every other Lemmy instance, they only know the ones they've talked to. All of the data is accessible if I know the hostname of a Lemmy instance, I just need to know the hostname first, and unless we build a centralized repository of every instance, we will never know of every single one. In the meantime, larger Lemmy instances have a large enough list of federated servers to get you most of the way there in terms of a directory, so maybe that's a reasonable stopgap.

I've noticed for my North American friends it's easy to convince them to move to Signal (from SMS or Messenger), but my European friends are all pretty entrenched in WhatsApp. On one hand WhatsApp is certainly more secure, but on the other we can't really trust a closed source implementation (and they'll still collect metadata which makes me uncomfortable).

I'm just glad I don't have to use SMS anymore honestly

I understand and value the idea of self-hosting or federation to decentralize services, but Signal is currently my most used chat app for the sole reason that I can tell a friend to go download it and it just works. Supporting self-hosted servers or federation doesn't necessarily mean that the UX has to be bad, but for small organizations I think the radical focus on a specific experience is the best way to make a good product, and if this is the sacrifice that was made so that we could have a simple, reliable, private messenger then I'm happy with that tradeoff.

As an example, chat protocols/implementations like Matrix have a lot of potential, but the foundational decisions around decentralization mean that it takes way more work to make it seamless to use. You can't download a client and start chatting immediately, you need to think about what server to connect to, and that's already enough of a barrier to make it a no-go for a lot of the folks I regularly chat with who just don't care enough about privacy/FOSS to put in the effort.

This is super cool, I'm hosting SnapDrop for this purpose and it's pretty slick, but I wonder how WebTorrent's performance differs for larger files

No specific indication, but as the organization matures and brings on new folks it's always a little uneasy to see the old guard leave. Only time will tell!

To be honest, while crypto is probably the closest we have to an actually private payment option (Monero etc), I'm generally not a fan of it for this usage because unlike the rest of the app, it has a much steeper learning curve AND is a common target for scams, which makes it much less approachable for the average user. I love Signal because my mom can use it and I can trust that she's protected, but I would not recommend she tries using the payment option within it regardless of what coin they use because the rigamaroll of going to some exchange to buy it is already a dicey proposition.

I'm cautiously optimistic that this isn't a warning sign. I can imagine wanting to do something new after spending so long working on one project, but if he left because things were straying from his vision of Signal that could be a bad sign.