Yeah, this is quite the confounding factor when judging the health of online communities/youtube channels/multiplayer games. Especially because the weather doesn't improve at the same pace everywhere, some years are naturally more "boring" than others, then we had the covid years which were outliers
"Synergistic Processing Unit" sounds like a term a middle manager at some hardware manufacturer would have proudly invented to describe some component of their newest """AI oriented""" product. Alas, Sony, Toshiba and IBM were 20 years ahead of the curve and put it into the Cell Broadband Engine.
Some people really are deciding to send youtubers death threats over the use of "AI AI AI" in entertainment software, eh? It's too bad the military-industrial complex doesn't show tech demos for their own AI research, with fancy marketing names, to the general public.
aaah "gamers"
i gotta say, one of the biggest problems in a lot of fandoms nowadays (not just the vtubing fandom) is that a lot of people there love fighting and arguing with others more than actually interacting with their interests
Yes, it's a centralized web2 service with slightly better auditability than the average web2 service. This doesn't mean it is a bad tool for the job. It's just meh.
New track now out on YouTube! And soon enough on other platforms too, once I stop being lazy and figure out what distribution service to use.
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 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.
