gbl08ma

I use some Flatpaks on Arch and Arch-based distros too. So what?

self-promotion measures were needed, sad that I won't be able to properly appreciate your work now that I realized what you were doing, and sad that I felt sufficiently emotionally affected by this to write a rant.

But seriously, really cool stuff, uncool spam.

...do you do video commissions?

Yours is definitely not the first botted account I see, but I think it might be the first who is actually promoting work that seems genuine and not some AI/finance/self-help/motivational/"tech bro" BS, so I think, for the first time, I'm just genuinely sad: sad that life is such that you felt these

for me, realizing that it's all inorganic really left a bad taste in my mouth, and makes me consider unfollowing and forgetting about your stuff. I think most people who notice will have the same reaction.

Like, I am a bit conflicted because I get that one's gotta "grab that bag," and to live off of art, getting a social media following feels like a must these days, to even see any bag grabbing opportunities. And I am 100% aware I wouldn't have found your account if it weren't for said spam. But,

Screenshot of https://pdsls.dev/at://did:plc:egjdrp7pjac6frfs4exrky7m/app.bsky.graph.follow showing a strategically short amount of inorganic follows happening every few seconds throughout a short period

Screenshot of https://pdsls.dev/at://did:plc:egjdrp7pjac6frfs4exrky7m/app.bsky.feed.like showing inorganic likes happening every few seconds throughout a short period

Man, your music and videos are so cool but spamming (un)follows and likes is really uncool.

The Age Verification Trap Platforms are caught in a dilemma: enforce age restrictions or protect user privacy. How are they navigating this tricky terrain?

spectrum.ieee.org/age-verifica...

the did:plc spec keeps changing, or the official implementations associated with it, because to some degree it can be tricky for me to keep up with, in a timely fashion.

I will definitely keep trying to work on didplcbft at my own pace, I really want to get to a point where there's a live testnet working that people can "participate on" by running their own nodes and stuff. I just doubt it'll ever get enough traction to go much further beyond that, particularly if

It is a selling point, but it's not unique to didplcbft (and if it is, probably not for long - it's nothing any ZIP file of the postgres/sqlite database used by the official read replica doesn't provide) and I'm not sure it will be enough to counter the disadvantages of its "heavier" approach.

...YMMV depending on the specs of your hardware, the network bandwidth, and so on. (by default nodes, limit incoming/outgoing bandwidth in p2p connections, this can be lifted in config; in any case, more peers with the same snapshot => faster snapshot downloads).

Maybe I misunderstood what you meant. If you were talking about the speed of spinning up a node and getting it to a point where the full PLC is ready to query, in my experiments it appears to take about 2 hours using a snapshot (of course, it will also depend on the age of the snapshot). Of course,

I think backfill speed is ultimately not too relevant, because it's a one-and-done event for the network (after it's done, it's just a matter of incrementally keeping up with new operations).

With some changes to the approach, maybe one could make it so that only a subset of nodes fetches each batch from the official service, but no matter what, the byzantine quorum needs to verify what it is inserting in the state, so at least two thirds of the nodes would need to download it.

The way it's working right now, the nodes all need to download the data from plc.directory in sync, 1000 operations per block, one block roughly every 1.5s. These parameters can be changed using constants in code but I wanted to be mindful of not causing too much load on the official service.

I wish I could move it to a phase beyond "experiment," but the fact that I am employed is unfortunate in this very specific matter. I also definitely don't have "10x energy"... so it is a mystery why I keep having ideas for, and going ahead with, projects that are larger than me.

With "no financialization" I mean that didplcbft in itself won't have any built-in incentivization mechanism (just like PDSes, relays, the HTTP protocol, etc. also don't have such built-in mechanisms), other than perhaps the "reputation system" which is specifically designed not to be a currency.

Fortunately I've kind of addressed this before too :D

People often run infrastructure even when it, in itself, doesn't provide the financial incentives; they run it because there are indirect incentives (not necessarily financial).

See the replies on this thread for more discussion:

I've explained in previous posts that I'd really like this to be decoupled from any cryptocurrency/financialization initiatives, in part because it could constitute a conflict of interest with my employer.

Those who just need/want to run read replicas (e.g. for "keeping the official service in check"), the new read replica they've introduced is likely good enough, meaning didplcbft will likely have a harder time growing a user base (which would be needed for it to succeed long term, as a P2P network).

I'm afraid that the official PLC read replicas project will make it so that didplcbft is mostly appealing only to "blockchain fans" because its main remaining unique ultimate benefit (the ability to also decentralize write operations) is really far-fetched.

(in contrast, among didplcbft nodes, that initial transfer using snapshots requires less than 40 GB of data transfer)

But you're right that _transferring_ the entire PLC from the /export endpoint represents roughly 100 GB of data transfer, that checks out with the numbers I've been observing in my tests.

FWIW my latest didplcbft code can fit the entire PLC in about 50 GB of space, in a ready-to-use format (i.e. non-archive). This was achieved by fine-tuning the settings of the IAVL tree library I'm using, there's much less redundant data being stored now. Also reduced SSD thrashing in the process.

gbl08ma.com/didplcbft A very experimental PLC implementation which uses BFT consensus for decentralization

I'm sure most of you participating in this thread are already aware of tangled.org/gbl08ma.com/..., but I'll toot my own horn here for posterity anyway...

A blockchain-based approach is certainly debatable, like anything in life. But blockchain != "crypto" and I'll try to prove that...

I believe atproto is decentralized.

Now I may be partial because I’ve worked in it for a while. But It’s all there, and it works in this fashion at scale.

I think sometimes it ends up being an issue and it’s not someone’s favorite way to the decentralize things and that’s perfectly okay.

Indeed, things are allowed to be unoriginal and/or too late for their time and/or just poorly executed, without it necessarily being the fault of corporate.

One could try to label them based on the domain of their handle, but that's not a job for my labeler; it isn't meant to be used for moderation, anyway. And then the spammers would just move to using different domains for their handles anyway. It is on the Blacksky team to curb the spam on their PDS.

Due to the way the Blacksky team has their domains set up, in practice all of these accounts are hosted in the same PDS and my labeler can't distinguish them. You can see in e.g. this account, that has since been taken down, that the PDS service is Blacksky pdsls.dev/at://did:plc...