<gchristensen>
I'm a little scared to dig in to my PR's remaining failure :x
<samueldr>
how scare are you on a scale of 53 000 000 rows being migrated?
<samueldr>
how scared*
<gchristensen>
I'd rather migrate another 110 million rows
<samueldr>
don't say that, or it might happen
<gchristensen>
lol
<ajs124>
About that whole migration thing: I'm still kind of unclear how this will affect small hydra installs. Do I need to do this whole thing manually as well?
<gchristensen>
quite likely yes
<gchristensen>
though maybe it could be made to run automatically during hydra-init
<gchristensen>
the down-side being if you have many rows, your hydra will be down for a long time
<ajs124>
We have <100k builds, so I think we'd be fine. TBH, worst case I drop the database and start from scratch. I just want to be prepared ^^
<gchristensen>
so much vacuuming
<gchristensen>
100k can be done in only a few seconds on a moderately powerful server :)
<gchristensen>
it took 84 seconds to just count the number of records inthe builds table
<cransom>
i must not have watched that in a very long time. i never noticed the 'ready kafaka?' bit.
<cransom>
s/kafaka/kafka/
<gchristensen>
guh 1987
wildtrees has quit [Quit: Leaving]
<colemickens>
gchristensen: kind of random, but you had mentioned ikwldpeppers (or something like that) working on Azure stuff a month or so ago. Do you know what came of that?
<gchristensen>
he's still suffering through afaik :)
<ashkitten>
apparently the pinebook pro is on par with lower end ryzen cpus :o
<samueldr>
on par how?
<samueldr>
(not that I doubt)
<ashkitten>
gf did a linux compile test and the pbp got 27 mins, her ryzen 5 2600 got 17
<ashkitten>
thats 62% the speed
<samueldr>
not bad
<samueldr>
yeah
<ashkitten>
and it's like, not an expensive laptop at all
<samueldr>
I think graphical acceleration is the main issue to solve with nixos now
<samueldr>
and well, the other small issues that are not nixos-specific
<ashkitten>
honestly i'm really impressed
<ashkitten>
my dream machine would be a risc convertible with at least 12 gigs of ram, a trackpoint nub, and one of those touchpads with physical buttons at both the top and bottom
<ashkitten>
and usb c
<samueldr>
hopefully a new SoC with a bigger RAM maximum will be usable soon for such an endeavour
<samueldr>
RK3399 is limited to 4GiB
<samueldr>
(and is getting a bit old)
<ashkitten>
ahh
<ashkitten>
yeah
<ashkitten>
unfortunately the pinetab is the same soc as the pinebook and pinephone
<samueldr>
yeah
<ashkitten>
otherwise i'd be pretty interested
<samueldr>
rk3399 was announced in 2016
<samueldr>
I wonder how it compares to low and mid-end 2016 chips in x86-land
<ashkitten>
if they released a pinetab with an updated soc and more ram i might get it
<samueldr>
I also wonder if qualcomm would be ameniable to working with a "open source friendly" outfit like pine64 with their IP
<ashkitten>
ehhhh
<ashkitten>
i wouldnt bet on it
<samueldr>
I wouldn't either :)
<ashkitten>
they've been notorious for antagonistic business practices, yeah?
<samueldr>
but they're the main name I know of that are "mobile" friendly and not older designs
<samueldr>
yep
<samueldr>
but... maybe no one asked?
<samueldr>
it could be that the OEMs themselves want those horrible misfeatures?
<ashkitten>
the oems definitely want garbage
<ashkitten>
but which misfeatures?
<samueldr>
biased opinion: having the firmware part of the main storage of the device, meaning that one slip of a `dd` and the device is now useless
<samueldr>
those new qualcomm laptops also have a completely bonkers eMMC layout where the partitions for the firmware are interpersed with the windows partitions
<colemickens>
gchristensen: I don't know what level of complexity they're aiming for, but if it's just a matter of basics, I might be able to help.
<samueldr>
so you can't just erase the whole drive or you, simply put, delete the bios
<colemickens>
I tried to help a way to contact that person, but couldn't figure it out.
<ashkitten>
i absolutely hate when things let you easily brick them
<samueldr>
and since qualcomm has some kind of "secure boot" scheme, you need a signed program to upload to the CPU to unbrick
<gchristensen>
colemickens: I bet they would like help. maybe you could get on sometime early your morning?
<colemickens>
I decided to try and get my nixpkgs PR count closer to 0 and my azure PR is a big outstanding one and enough people were interested that I want to finish it.
<samueldr>
those often get leaked, but that's not a guarantee
<ashkitten>
there should be immutable backup firmware somewhere no matter what, you shouldnt be able to brick a device
<colemickens>
gchristensen: sure I can do that in the next day or two
<gchristensen>
cool
<samueldr>
exactly, the design for the firmware of chrome-based devices are imo the best example we have right now
<samueldr>
while there is one chip you can't control, its firmware source code is available, so you can compile and compare
<samueldr>
that chip allows you to recover if you erase the (separate) firmware chip
<ashkitten>
huh
<ashkitten>
neat
<samueldr>
and unlocking your device for this is done in what, AFAIK, is a secure way, though understandably annoying
<ashkitten>
but yeah like, imo it's so antagonistic toward the open source community if you make flashing a device dangerous and difficult
<samueldr>
oh, and it runs coreboot, and the chrome hardware team contributes to mainline coreboot
<samueldr>
on x86_64 devices you can generally install tianocore payloaded coreboot trivially
<ashkitten>
that's cool
<samueldr>
arm devices you probably could, but there's not the community building the equivalent
<ashkitten>
i wish arm devices were like, easier to get working?
<ashkitten>
x86 machines you just dump some files in a fat32 partition and boom you're up
<ashkitten>
the process on arm is not really comparable
<samueldr>
most often it comes from the fact ARM SBCs are "bring your own firmware"
<samueldr>
x86_64 would probably be just as annoying if the firmware wasn't part of a chip already
<ashkitten>
is ebbr comparable to the bios spec?
<samueldr>
not exactly
<samueldr>
but it mandates UEFI should be used
<samueldr>
and how to store multiple firmwares together side-by-side
<ashkitten>
so boards that support that spec should be as simple to work with as x86_64?
<samueldr>
but also mentions that's when the implementor doesn't want to put the firmware on a separate chip
<samueldr>
yes
<ashkitten>
that's very exciting
<samueldr>
you can technically make the Pine64 A-LTS EBBR compliant, and the pi, somewhat
<samueldr>
when done, you can download the UEFI aarch64 iso for nixos and just boot it
<samueldr>
I have here one pi with tianocore on SD card, and that pine A64-LTS with u-boot on SPI
<ashkitten>
oh very cool
<samueldr>
they both can boot the aarch64 iso like you would
<samueldr>
uh, like you would on x86_64
<samueldr>
now, it's more about mainline linux being less of a pain
<samueldr>
and that's part of the issue here...
<samueldr>
you know how it's bring-your-own-firmware?
<ashkitten>
sure
<samueldr>
they uh... made the bad decision (imo) of being keepers of device trees
<samueldr>
and "fix" all kind of things in device tree properties
<samueldr>
if you want to boot the most recent kernels, you also have to use the right device tree
<samueldr>
which technically can be done by a bootloader
<samueldr>
but it's not part of the UEFI spec or EBBR (AFAIK)
<ashkitten>
i'm a bit confused
<samueldr>
so, now you have to update your firmware to get the right device tree to boot the most recent kernel, or else things may fail
<ashkitten>
oh i see
<ashkitten>
that is bad
<samueldr>
imagine if on x86_64 you had to update your bios to boot kernel 5.5?
<ashkitten>
hah
<samueldr>
they _already_ have to handle this in-kernel rather than involve updating unrelated parts for x86_64
<ashkitten>
as if motherboard manufacturers would update anything if they didn't have to
<samueldr>
I'm a bit sour that this is not done that way on aarch64
<samueldr>
since this means that EBBR can't really work until the kernel stops doing what they are doing
<ashkitten>
yeah i see
<samueldr>
or handle loading dtbs as part of a "kernel" task
<samueldr>
it would be perfectly fine with me if, during early boot, the kernel somehow looked at the `compatible ` string for the board, and then loaded the "right" dtb (according to the kernel) that would be built-in the kernel imag
<samueldr>
image*
<ashkitten>
right
<samueldr>
rather than assuming it will be done by the bootloader
<ashkitten>
that makes sense
<ashkitten>
at least the silver lining for nixos is that we can effortlessly revert to a previous generation that worked
<samueldr>
we can't with EBBR
<ashkitten>
no?
<samueldr>
or, uh, we can't if the bootloader doesn't load the device tree for the right kernel
<samueldr>
let me rephrase again: we're stuck with *one* device tree that the firmware knows about, with UEFI
<samueldr>
unless we start adding better generic FDT support in e.g. grub
<ashkitten>
grub supports aarch64?
<samueldr>
yes
<ashkitten>
that's news to me
<samueldr>
that's what is used by the UEFI installer on aarch64
<ashkitten>
huh
<samueldr>
and on tianocore on the raspberry pi it's fully graphical
<ashkitten>
ah, neat
<samueldr>
not sure with the most recent u-boot on Pine A64-LTS, but it falls back to graphical on 18.09
<samueldr>
ooooh, pinebook A64, it's graphical
<samueldr>
my pinebook A64 uses UEFI boot through trickery
<samueldr>
when I bought it I was assuming it had an SPI flash, it doesn't :(
<ashkitten>
ah
<ashkitten>
so let me get this straight: linux doesn't try to load the correct device tree, which means if you try to boot a kernel that expects features or fixes that aren't in the device tree your firmware loads, it won't boot. yes?
<samueldr>
it may boot, but that thing it fixes won't be fixed
<samueldr>
it's also, imo, an issue with multi-operating-system interaction
<samueldr>
all the BSDs, haiku, they could very well do the same thing
<ashkitten>
i'm confused the issue if it does in fact boot. if i haven't updated the firmware to include a fix, i would expect my system to boot without the fix
<ashkitten>
what is the deviation from expected?
<samueldr>
that's it, it boots, but the fix isn't there
<samueldr>
it could be something like configuring the display driver for the panel
<samueldr>
maybe in the past the driver hardcoded a refresh rate
<samueldr>
now they want to make the driver more generic, move the refresh rate to a _configuration_ inside the device tree of the devices using that driver
<ashkitten>
then when i boot it won't initialize the panel because it expects the fix now?
<samueldr>
though, tbf, it _is_ a hard problem, fixing stuff after the fact
<samueldr>
ashkitten: pretty much, the module could fail since there is no way to know the refresh rate
<ashkitten>
so you want linux to vendor the device tree so it will stay in sync, yeah?
<samueldr>
they do, but they leave *loading* their updated device trees as an exercise to the system implementor
<ashkitten>
so again the silver lining as far as i see is that if i update the kernel but the new device tree is not installed, i can still revert to the previous generation right?
<ashkitten>
as long as grub is not somehow broken by that
<samueldr>
yep
<ashkitten>
this all makes sense to me
<ashkitten>
thanks for explaining
<samueldr>
thanks for listening
<samueldr>
I hadn't thought up until now that it might be possible to do something kernel-side to build-in all device trees and manage loading them
<samueldr>
as long as it's a task that happens before it wants to be used, it should be possible, even conditionally loading a device tree overlay that's built-into the kernel
<samueldr>
like dtoverlay=rpi3-spi-is-now-a-chicken.dtbo, that would somehow map in the built-in table to the right dtbo and the kernel would overlay it
<samueldr>
(does it show, that I've never had a real use for dtbos so I don't know what one would actually be named?)
<ashkitten>
ahh
<ashkitten>
lol
<samueldr>
looking at feasability, dtbs are ~9.1MiB, this would be added on top of 35MiB kernel images for "defconfig" mainline
<samueldr>
which at this point I think shouldn't be considered "added weight" as you *anyway* need to ship those file
<samueldr>
I hate this, I don't have the time to do this, but I feel this would be immensely beneficial to improving the story of booting kernels on device tree platforms
<samueldr>
hey, someone, steal my idea, implement it, I promis I'll (not) be mad that someone did what I wanted to
<samueldr>
depends if you want to spite or help me
<samueldr>
oh, and continuing from a previous tangent, another thing that muddies the water with booting in ARM-land is how u-boot is both the firmware *and* the bootloader in most situations
waleee-cl has quit [Quit: Connection closed for inactivity]
garmanarnar has joined #nixos-chat
KeiraT has quit [Ping timeout: 240 seconds]
ajs124 has quit [Remote host closed the connection]
<colemickens>
I like seeing related tech in comments, but the comment didn't really make sense. The stuff listed about Guix is the stuff it inherited from Nix, as I understand it. It didn't really highlight why I'd want to checkout Guix if I were already happy with Nix.
<DigitalKiwi>
...did you expect better from the orange site?
<colemickens>
I mean, of course not. But more from a fellow Nix/Guix evangelist, yes :)
<colemickens>
I'm just happy to see mentions of Nix and Guix accelerating. I don't think I'm imagining it.
<drakonis>
the comment wasnt very good, but there's a variety of things it has inherited and augmented through scheme
<drakonis>
i'm hoping to see see some measure of an arms race between both, to see how much either will grow
<drakonis>
the writer of the guix comment wrote a follow up at least
<drakonis>
not much either
<drakonis>
hm, an evolutionary race rather than arms race
<infinisil>
Hm, we could really use some roadmap for high-level goals to improve Nix
<drakonis>
indeed,
<infinisil>
Would imo include: Improving docs, reducing nixpkgs complexity, improving quality of nixos modules
<drakonis>
but look at this person talking about how nix is dropping osx support for ideological reasons
<drakonis>
reducing nixpkgs complexity is a lofty goal
<drakonis>
a lot of things depend on it
<drakonis>
as is, so changes will likely require a lot of sweeping to improve it
<infinisil>
Yeah
<drakonis>
it'd also significantly cut down on the package count
<infinisil>
Also another thing: Improving and unifying support for different language builders
<drakonis>
yes please.
<drakonis>
doing away with builder automagic would be pleasant
<drakonis>
reduce build process assumptions
<drakonis>
there's a noticiable amount of per package hooks
<drakonis>
i'm not sure if i can sufficiently appreciate the build being modified by my input packages
<drakonis>
rather than some deliberate action such as picking the build system
<drakonis>
fixing that would likely break everything in nixpkgs, right?
<samueldr>
right, that's not even the root of the issue
<samueldr>
it would break users of nixpkgs
<drakonis>
the whole thing is approaching non maintainability
<samueldr>
I was only answering the specific "would break everything in nixpkgs?" question
<drakonis>
fair enough, the answer was already known.
<samueldr>
I feel this is something that needs to be Proof-of-concepted and RFC'd rather than shouted in the void that is the off-topic nixos irc channel ;)
<drakonis>
hah, alright.
<drakonis>
its a lot of work to completely redesign nixpkgs
<samueldr>
I agree that we shouldn't necessarily sit on our hands with the status quo
<samueldr>
and yes, it's a big, huge task
<samueldr>
any effort, even if it's a failure, is a good place to learn what to do and what not to do
<drakonis>
i honestly dont have enough dominion over nix lang to do such a thing
garmanarnar has left #nixos-chat ["WeeChat 2.6"]
endformationage has quit [Quit: WeeChat 2.6]
drakonis has quit [Ping timeout: 265 seconds]
vesper has quit [Ping timeout: 240 seconds]
vesper11 has joined #nixos-chat
lovesegfault has joined #nixos-chat
drakonis has joined #nixos-chat
cole-h has quit [Ping timeout: 268 seconds]
drakonis has quit [Ping timeout: 240 seconds]
<ashkitten>
samueldr: oops.. i thought gf was talking about her desktop when she said "ryzen" but she meant her laptop, with a 2500u
<ashkitten>
i feel very silly now
makefu has quit [Quit: WeeChat 2.6]
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-chat
__monty__ has joined #nixos-chat
colemickens_ has quit [Quit: Connection closed for inactivity]
<eyJhb>
Tried to sell LEGO on NixOS during my last meeting. They seemed somewhat interested :p
<Taneb>
I've definitely asked this twice before, but LEGO here means some software that your organization (university?) uses, and isn't in fact plastic building blocks
<Taneb>
Right?
<eyJhb>
Taneb: LEGO in this case is lego.com, so the plastic building blocks :p
<eyJhb>
I can understand the confusing, isn't always easy keeping track of :p - But I was at a meeting last year, and tried asking what distros they used etc. where I mentioned NixOS would be nice if they wanted to test it out
<eyJhb>
The conversation quickly turned to Golang, since one of the devs had some Golang code he really wanted to show me
<eyJhb>
Is there any "number" of what the biggest company is, that uses NixOS internally?
<eyJhb>
Like, how many actual machines
<Taneb>
I can give you a very low lower bound
<eyJhb>
Taneb: Hit it
<Taneb>
We have 2 NixOS machines
<__monty__>
IOHK must run a few, clever?
<eyJhb>
Taneb: that is less than I have at home :p
<eyJhb>
Reminds me, I should update the router now that I am alone
<worldofpeace>
why do you need to be graham@grahamc.com? hehe, an instance for your fans?
<gchristensen>
because I don't want to have my identity tied to another org like that. unlike Twitter, the server you're on means something and it ties me to them in a way I don't like (and have avoided for email for at least a decade)
<worldofpeace>
I see what you mean, but with the fediverse it's not as chained like that. I think? Well I guess then you'd have multiple identities if you had to switch an instance
<worldofpeace>
* multiple online identities
cole-h has joined #nixos-chat
<infinisil>
worldofpeace: Doesn't mastodon support changing instances now? I think I read something about that
<worldofpeace>
etu: oh, hi 👋 You should probably add github to your profile metadata
<qyliss>
gchristensen: git am --reject
<samueldr>
that issue is extremely frustrating
<samueldr>
since it's possible every one of the corroborating comments "it happens to me too" are different issues
<samueldr>
and short of having the same exact setup, computer, bios configuration, usb drive even, it's hard to reproduce
<samueldr>
funny how I can bet I can scrounge up the other distros bug trackers and find similar unsolved issues
<samueldr>
jokes?
<samueldr>
and... even more frustrating: the bootloader *completely changed* since this issue was opened
<samueldr>
so if it's a bootloader issue, rather than a kernel issue, it's not even relevant
<samueldr>
I'm willing to bet exposing the "new kernel" variant of the issue could have helped a couple of those facing the issue
<samueldr>
I'm not even sure UEFI is relevant for some
<ashkitten>
emily: i think the only issue would be that other servers don't support the migration feature
<samueldr>
the more I think about it, the more it seems to be a failure of the "bug tracking" software with github
<samueldr>
we can't simply pick a comment and split it into its own issue to work out
<ashkitten>
emily: you should be able to support migration from any server that can mark you as "moved" to any server that can send out the migration event
<samueldr>
so we have this omnibus "I can't boot" issue that is seemingly unsolvable
<emily>
ashkitte1: it's complicated; other servers can have fundamentally different data models
<emily>
I forget the details but I remember it being a mess
<ashkitten>
it's not that complicated really
<ashkitten>
it's just a matter of letting servers know that you've moved
<ashkitten>
oh you mean importing/exporting follows?
<emily>
well, ok
<emily>
I meant if you wanted to migrate posts, follows, etc.
<ashkitten>
migrating posts is not possible at the moment
<emily>
right
<emily>
activitypub basically only standardizes post interchange to my understanding so it'd be hard to do fully-featured migration without speccing a lot more mechanism/policy?
<ashkitten>
migrating follows is easy, i know mastodon and pleroma can both export/import a csv of your follows
<emily>
I'm no expert though; I don't even have a fediverse account ^^;
<ashkitten>
the problem with migrating posts is partly that of identity verification but mostly that of federation
<ashkitten>
you could in theory rewrite the posts and store them locally in your database as if a local user created them, but you would have to manually notify every server that they exist
<ashkitten>
as far as i know there is no way for a server to federate a post from itself without it appearing as if it was just created
<ashkitten>
er like
<emily>
right
<ashkitten>
there's no way to federate a post and not have it show up in people's timelines right away
<ashkitten>
because mastodon for instance doesn't sort timelines chronologically by creation, but chronologically by time of reception
<ashkitten>
which, to be fair, is mastodon's own problem. but it does put a damper on our ability to federate older statuses without spamming followers
<ashkitten>
ofc there's the added issue that we should really be batching these somehow so that every server in a metaphorical 10 mile radius doesn't have to process a 100k post history at once
<ashkitten>
but even that poses its own issues
<ashkitten>
you can see why this hasn't been solved yet, i hope :p
<emily>
yeah
<emily>
hence me replying to 「"easy and painless"」 :p
<emily>
(and why I still don't have a fediverse account yet; need to set something up on emily.moe)
<ashkitten>
good luck
<ashkitten>
you've been working on that mastodon pr for nixpkgs, right?
<__monty__>
Did mastodon get more popular than diaspora because of UIcandy?
<ashkitten>
because it looks nicer, you mean?
<__monty__>
Yeah, diaspora dates much further back afaik?
<ashkitten>
i don't know much about diaspora* to be honest
<ashkitten>
i know they use their own protocol
<emily>
nope, not me
<__monty__>
Also, doesn't that post ordering cause replies to be ordered before the comment they're meant as a reply to sometimes?
<ashkitten>
__monty__: yes, if someone's sidekiq queue is acting up. and if the reply is processed first then it won't get attached to the parent
<__monty__>
Ouch, that sounds horrible.
<ashkitten>
but to relay some history, mastodon started out as gnu social compatible because, as i recall, eugen wanted a gnu social frontend that was more like tweetdeck
<__monty__>
Tbh, everything I've heard about ActivityPub (including from the original author) is horrible.
<ashkitten>
the current state of the activitypub fediverse doesn't quite follow what chris had envisioned
<ashkitten>
fwiw i think a lot of that is eugen's fault
<ashkitten>
(it's partly his fault that gnu social people hate mastodon users, too)
<__monty__>
Why is that? Do they feel cheated?
<ashkitten>
because he abused the ostatus spec to graft on features he liked, and didn't care how they impacted the experience of existing ostatus users
<ashkitten>
and then mastodon users came along and there was a lot of fud spread about gnu social because it didn't support the features he had grafted on
<ashkitten>
things like post visibility levels weren't a thing until he went and created them, but if your post federated to a gnu social instance anyone could see it
<ashkitten>
and mastodon users were lead to believe this was an intentional thing gnu social people were doing
<ashkitten>
if you look at mastodon's history there's a number of instances of mastodon users being real shitty to people on other federated softwares, spreading fud, etc. and a lot of it can be traced back to "eugen implemented a thing in a bad way and didn't stress the caveats enough"
<emily>
to be fair i think you'll also find a number of instances of literal nazis on gnu social being real shitty to people on other federated software too...
<etu>
worldofpeace: Good point, I'll do that
<ashkitten>
emily: yes, and you'll find mastodon instances with nazis as well. and?
<emily>
I think there would be a substantial amount of strife between gnu social people and any new influx of people as a result of that regardless of how server/client devs behaved
<ashkitten>
i mean
<ashkitten>
i don't know that there's any substantially higher percentage of nazis on any one software
<ashkitten>
and if there is i don't think that's a result of the software itself
<emily>
shrug I don't remember the last time I found myself on a GNU Social instance and thinking I'd want to ever interact with the people on it, but this is mostly cached memories from years ago, and there's obviously sampling bias there
<emily>
nothing to do with the software though, yeah
<ashkitten>
i know pleroma is claimed to have a high percentage of bad actors but that's partly down to it being easier to spin up a pleroma instance
<emily>
I just think some kind of schism was probably inevitable given sufficiently divergent userbases existing in a very incomplete federated system
<ashkitten>
for the record i don't like the pleroma devs personally, but i don't see anything wrong with their software
<emily>
part of the reason I don't have anything on emily.moe yet is because all the server software seems not great, tbh >_>
<ashkitten>
but i can tell you, having been on the fediverse watching all of this happen since 2016, a lot of strife could have been avoided if eugen had accurately described what his features could and especially could not do
<emily>
mhm
<ashkitten>
and if it had been portrayed that instances that don't respect his features are not necessarily malicious
<emily>
free software is hard; controlling what a large userbase thinks is even harder
<emily>
not to necessarily say he did nothing wrong either since I don't know the details
<emily>
but "interoperating with arbitrary existing clients in a federated system while still implementing important new features at a reasonable pace /and/ communicating proactively about all of that" is a tricky balance to strike
<__monty__>
This visibility level thing seems particularly flawed though.
<emily>
yeah that's not great
<__monty__>
If the servers have to decide whether or not to show a post to someone, all anyone has to do to see things they're "not supposed to" is run their own server instance.
<ashkitten>
it doesn't help that there isn't a great way for a server to communicate what it doesn't support
<__monty__>
The semblance of privacy where there is none is particularly toxic.
<ashkitten>
__monty__: well, assuming someone who is meant to see the post is also on your instance
<__monty__>
You said these posts were federated over to gnu social servers though?
<ashkitten>
right, if the post is addressed to someone on a gnu social server
<__monty__>
Even within the same instance it sounds like the posts would be stored in cleartext. That's still a pretense of privacy.
<emily>
that's a pretty wide definition of pretense
<emily>
some degree of trust may be less than ideal, but it's not a dealbreaker
<emily>
(trusting arbitrary servers is of course unreasonable, but two people both on instances run by people they trust – why not?)
<ashkitten>
when you sign up on an instance it's assumed that you trust the admins of your instance
<ashkitten>
when you talk to someone on another instance you know that an admin of their instance could read that if they are malicious
<__monty__>
Except apparently most people didn't understand at all.
<ashkitten>
if you don't want real privacy guarantees use matrix with e2ee
<__monty__>
Hence the effectiveness of the FUD.
<ashkitten>
people didn't understand the difference between a software not having support for post privacy vs actual malicious behavior
<__monty__>
I hope that's a mistaken negation? Has Matrix e2ee been found to be vulnerable?
<ashkitten>
sorry, yeah
<ashkitten>
messed up that sentence
<ashkitten>
if you want real privacy guarantees use matrix with e2ee
<__monty__>
I guess I don't consider a communication between N people private if N + x, where x > 0, people can listen in.
<ashkitten>
my point is, eugen didn't say that post privacy would have to be implemented in a server for it to work, so people thought the only reason post privacy was broken on other softwares was that the admins were actively publicizing their posts
<ashkitten>
and it's not just about private communication (individually specifying recipients) it's about posts with followers-only visibility too
<__monty__>
Thanks for the glimpse into the fediverse. Once again I have to say I've been discouraged from participating.
<ashkitten>
shrug
<ashkitten>
i think the problems have drastically decreased, at least in my circles
<ashkitten>
ofc ymmv, but i think it's at least better than birdsite
<__monty__>
The problem is a completely broken system built atop broken foundations by people who seemingly don't seem to care about what's important to me in such a system.
<emily>
22:19 <__monty__> I guess I don't consider a communication between N people private if N + x, where x > 0, people can listen in.
<emily>
this isn't the same as disregarding all distinctions between the values of x
<emily>
I'd ask if you ever use telephone calls but knowing the crowd maybe you'd bleed out to death before giving the emergency services your address :p
<__monty__>
I don't participate on twitter. But that does have an undeniable network effect going for it.
<ashkitten>
i think you're being a little overdramatic
<__monty__>
Choosing to share private information is very different from being led to believe communication is more private than it really is, emily.
<emily>
it is true that social software is not built for utmost privacy above all else
<emily>
I think you'd prefer antisocial software, which exists, and is valid... but is never going to replace Twitter
<ashkitten>
maybe you'd like scuttlebutt
<ashkitten>
though i've heard it's very hard to implement the protocol in anything but javascript
<__monty__>
I don't really care about replacing twitter tbh. Hence my apathy towards the fediverse.
<__monty__>
I do like what I've seen of scuttlebutt more than what I've seen of the fediverse.
<__monty__>
Can't imagine how being so tied to JS came about though. And that definitely sounds like a problem.
<__monty__>
The social platform I like best is IRC, mainly freenode.
<ashkitten>
i use matrix when i need privacy, i use fedi to talk to my friends more generally
<ashkitten>
more like a forum (in the traditional sense of the word)
<__monty__>
Thanks for the conversation. nn
<ashkitten>
np
__monty__ has quit [Quit: leaving]
drakonis_ has joined #nixos-chat
tilpner has quit [Read error: Connection reset by peer]
tilpner_ has joined #nixos-chat
KeiraT has quit [Ping timeout: 240 seconds]
KeiraT has joined #nixos-chat
KeiraT has quit [Remote host closed the connection]