asdkhadsj

> They just never feel as good as purpose-built apps with good workflows. If you know of one that does, please do forward it on because I'd love the inspiration.

I think the flaw here is that you're (likely) comparing purpose-built with unrelated unix-like apps.

What could have been done here with Keybase, is a purpose built app composed of unix-like tools, all controlled and implemented towards the purpose-built app. Aka the IM would be unique if you wanted it, or bundled with the FS, but both would be first-class Keybase citizens.

Unfortunately most companies don't put the time or effort into letting people consume parts of their offerings. It's all or nothing. Which is the complaint here, imo.

I feel like everyone is talking past each other. Or perhaps the definition of wealth is failing this discussion. Telling a family struggling to make ends meet that they are wealthy seems of little value. Depending on the scenario, they could be one job loss away from having nothing just like one of your families a state or two east.

Now that same family, income and house with a paid off mortgage is in an entirely different situation.

The difference is the wealth they accrued in paying down their mortgage. They claimed value in doing so. But merely having a massive mortgage in the Bay Area does not _inherently_ equate to wealth.

To agree with you, It's even more complex than even you outline, too. Wealth is, imo, a relative profit and cost of living expense calculation, regardless of how much you make. Ultimately it doesn't matter where you live or how much you make, you can be living paycheck to paycheck in almost any scenario.

There are definitely subtleties, like how feasible it would be for you to reduce expenses while keeping your income the same. Life.. gets complicated.

Warning: A bit of a ramble about my experience trying to use SSB for my "application".

I really enjoy SSB, conceptually. In reality I've had a fair amount of trouble getting started writing an application in it. Notably, I have difficulty knowing what patterns are good or bad in SSB.

As far as I can tell SSB utilizes effectively a commit ledger for user data. This is fine, but some of the specifics of my application mean that I feel the need to create many sub-identities so that revisions to a piece of content don't bloat the parent identity when syncing to mobile/etc.

Strangely, I've got a fair bit of experience in these types of designs - as I've written my own distributed storage for the application in question in many different forms (various ledgers, CRDTs, etc). Yet my issue is that I'm unsure what is considered "bad form" for the SSB crowd. I don't want to write an application for SSB but written in some form of SSB anti-pattern.

Combine this with SSB not having well established[1] implementations in my language of choice (Rust), and all around as much as I want to use SSB as the foundation for my app the protocol was just a bit of a heavy burden currently. I care what the SSB community thinks because I don't want to just "use" the SSB protocol, I want my application to join the SSB hubs/networks and share data.

I've looked a lot into this, but I still struggle to conceive exactly how my application can fit into the SSB ecosystem, if at all. This isn't a complaint post, just sharing some personal thoughts and my confusing history with SSB.

Love the project, and I especially love the design of gossip, person to person based applications in this day and age.

[1]: Rust does have a handful of SSB libs, but I think I'd be looking for a full, batteries included library. Everything I've seen is quite low level SSB.

Yea, agreed. I've had tons of problems with Windows, and over the years I ended up using Zoom because it was rock solid compared to the competition[1]. The comparison seems unfair, perhaps too kind to windows[2].

[1]: This was several years ago, competition these days may be more on par with Zoom. [2]: I imagine windows is becoming more stable these days. Again, my comment may be unfair to modern windows.

Awesome, I look forward to viewing them! Unfortunately I'm slammed at work so it'll be another few weeks before I have time for some side projects (like Godot) so don't hold your breath on my feedback. I look forward to watching these. Thanks!

You raise a good point, but sidestep a good conclusion I feel like. I can agree that it is surprisingly similar. However the root of the issue is that we need to speak in terms of environmental impact to get to Revenue.

I think the (implied) argument that the GP is making is such that Bitcoin is having too large of a cost to the value add to society.

I have no idea if this is true or not. I don't even know how we can quantify environmental damage relative to revenue.

Yup, that's exactly where I sit. A well implemented VPN is useful because I heavily distrust my ISP. I _could_ use some other big VPN provider, I guess, but I've always admired the tech stack of Cloudflare.. so I'm interested.

And fwiw, since I'm sure someone will think it - I don't want to manage my own VPN on some remote server. Not only would I put myself at risk because I don't have the experience to manage a secure server of such importance, but all I did was move my risk from my ISP to some other endpoint (VPS hosting/etc).

It feels like a game of risks no matter what you do.

I feel like your arguments are being disingenuous. All I can think of to summarize it on is for the same reasons I might want to host a file on IPFS, I may also want to use my central Git repo (the one my team pushes to) on something like IPFS.

Yes, I could host my file on Github. However I think it's well beyond my patience to argue for why IPFS(/sia/etc) should exist, in this conversation.

If you see no reason why someone would want to host anything on IPFS/sia/etc over Dropbox or Github, I'm not the person to change your mind.

This discussion merely spawned because I thought I had an idea on what the hell Dgit even is. I didn't write it, have never used it, and know next to nothing about it. Merely, I had envisioned a use case for my team using Git on IPFS, and mentioned that in these comments.

I'm confused; you object with my use of decentralized, but then argue (it seems) that distributed also does not fit the bill.

So.. I think we have a fundamental failure in communication here. It's difficult to discuss decentralization or distributed designs when, well, we can't even refer to the platforms that advertise themselves as such. Ie, I did not make this terminology. The platform we're discussing literally advertises itself as such in this title.

I'm not sure what's even being discussed anymore.

You can set up a backup Github? So you mean, you'd run like, an in-sync Gitea or Gitlab, and when there is an issue with Github your team and deployment methods (CI/etc) would automatically switch to that backup (temporarily or permanently)? That seems.. convoluted.

I feel like I'm repeating myself, but the advantage is being distributed. Distributed systems usually aim to be resistant to these types of issues. I'm a bit confused at your question. Are you asking why being distributed is good? Or are you asking why being distributed is good in this case?

If you're asking the former, I don't think this convo is in scope of explaining distributed vs centralized.

If you're asking the latter, why would this case be any different than any other case? You have a centralized entity and a while bunch of community and tooling built around it. Why wouldn't you prefer that out of control of a single entity?

The very argument against centralization is built into the foundation of Git itself. Yet you're asking why someone might not want centralization for the rest of the non-Git components[1]?

[1]: "non-Git components", While the source code is tracked via Git, I just mean the centralized entity your CI/CD/etc is hooked up to is it's own thing.

You can, with downsides. Uninformed ads have less value. You can also make people pay, and have no ads.

You can do lots of things.

Payment definitely is needed, unless you're offering to host it for them.

I hate ads just as much as everyone else, but if that's how they are planning to pay for hosting/time, it is absolutely needed.

Theoretically the difference is that it is.. well, distributed. Aka any benefits you'd attribute to having a file on IPFS over Github could apply here.

Which is to say, if Github goes down, gets blocked, blocks your team, etc; your team can still push to the "centralized" repo, etc etc.

> There's no such thing as a "master" repo in Git. "origin" is the default name for a cloned remote, and the convention used for adding a default remote, but nothing distinguishes the origin remote from any other remote. It isn't a master remote other than being default.

You're over thinking my example. As I said, by "master" repo I meant the centralized repo that many _(most?)_ git users have, somewhere. Aka Github, Gitlab, etc.

You're conflating Git's design with users patterns of centralization and distributed teams. Notably that often there is a single, centralized branch(es) on a single repo that everyone merges to.

This centralization could be distributed. It sounds trippy, but as you put it if your origin is on IPFS, you effectively have a single, mutable repo instance hosted on a decentralized platform (IPFS).

My guess is that is what Dgit is. A single mutable instance, hosted on a decentralized platform (Sia).

So back to my example, many people do indeed have a "master"/centralized repo. It's not a part of git, it's a user convention on top of git. But I didn't say it was in git.

Perhaps the Sia node gives you access to a "master" repo. Aka a single entity that represents a centralized repo, but hosted on a decentralized system.

Not sure though.

I too am confused.

My immediate thought was that Dgit offered a centralized remote, packaged around decentralized technology. Which is to say, many people have a main "master"; a single, centralized repo/branch. Dgit might be offering the same thing, but hosted in a decentralized fashion. I could see the value in this for backup, I suppose.

Sure, Git is decentralized but many of us still prefer having some centralization. Bundling that up into a decentralized system (aka no third party host) has some value.

Though really to me if I was avoiding Github/Gitlab/etc, the primary value add I'd want to see is all of the Github/Gitlab UI features. Notably pull requests, code reviews, comments, basic issue tracking, etc.

Another approach which I've liked in the past to solve this issue is to generate your README's from Rust Source. This has the same net output but the readme lives within Rustdoc.

I think I prefer it living in Rustdoc because then your README is also on docs.rs and whatnot.

But, I can see some downsides with that too. Not every README should be identical to the API docs. Not sure where the balance should sit.

I too find it quite nice. Though when I was starting out I found it exceptionally confusing. Notably the `impl` section towards the bottom. Even today, while I understand that section no problem - I don't usually find it too useful. Likely because the impls in Rust can be a bit weird. Ie Foo might impl `Responder` but only if `Foo` also implements `Serialize`, and those sort of scenarios have happened enough that I usually just ignore the bottom impl section. Not to say that the documentation is incorrect at all, I'm merely explaining how I have "adapted" to scenarios of the past - which could be confusion of my own making.

But.. aside from that, I quite like Rust Docs. I also especially love how I can write tests in them, link to other types and modules like `[Foo]`.

My complaint list for Rust Docs is surprisingly short honestly. Especially since they fixed the slow page loading on huge impl lists.

In fairness, as a Rust dev my computer sounds like it's a jet engine anytime I compile. I wouldn't even think about using a slimmer CPU. Not that you're wrong, it's just where my head is at haha.

Yup. I don't agree on the perspective but you're totally right. My wife works in a state with issues like this, and her very modest city (capitol, but not as big as SF or Seattle) has enough homeless people that all sorts of crime is on the rise. Restaurants were closing (before COVID..) because people wouldn't go to the restaurant anymore. There were literal camps in parking lots and the police did nothing.

I personally think it's a sad state of our society that we let this happen. These people are either in need of help, or mental help. This is not an acceptable way of living.

1. Give help to all those who simply need some help. 2. Give mental help to those who cannot see living in filth is not a healthy state of being. 3. Let the people who just want to live "free" go live in the woods and form a co-op or something.

I unfortunately see no reason why camping on the streets or next to interstates should not be strictly enforced. But to manage this, we need social programs for #1 and #2. These people aren't all criminals, we can't simply lock them up in jail/prisons. It would also exploit them to do so. We need human programs focused on helping people, and fast.

> This sort of thing is a privacy disaster. I wouldn't set foot inside a store that does this.

If they make it accessible enough, all stores may. Even if they don't, I imagine all stores will have something similar in some timeframe. So.. what will you do then?

Not to mention, if someone manages to make a useful product that benefits users and makes themselves money isn't that exactly what we want? Rarely do incentives align with consumers these days.

> I'm looking forward to seeing this project mature as well as have some more layers build on top of it moving forward. I really wish the client offered synchronization or access across multiple devices. For now you have to try third party layers on top of Sia to accomplish this.

Yea I'd actually pick it up now and give it a try if it had this feature.

Of course, but how would they know? The vector I refer to is my ability to create "evidence" and report you to their customer service.

Eg, i'd wager the GGP comment who reported 26 domains did so in a manner that would be fairly easy to fake. So what is the requirement of reports? Too loose and it's easy to fake, too strict and it becomes to difficult to report _(or too costly to verify)_.

> I wouldn't expect Namecheap, a low cost registrar with "cheap" in its name, to have the legal resources to investigate or make a conclusion for each accusation that comes their way for one of their 10 million domain names.

Exactly. And if they _did_ I'd be just as concerned that they're now allowing a vector to take domains down.

Balancing the two is difficult..

Yea, I think many in the tech circles forget how predatory a lot of industries are. My first "real" job was a state job (good benefits, good hours, etc), and eventually I migrated to tech. After years of that I met my wife, who worked retail.

At basically every aspect of her job it felt like her employer did not respect her as a person. Her work hours weren't steady, her pay wasn't good, she was constantly at risk of losing her "full time" status and if she did lose that she could drop down to random ~5h/week slots. Her employer wouldn't even fire you, they would just drop you down to basically no hours until you had to quit and miss out on unemployment.

Most of the staff she worked with in fact, most of which I'd argue were full time employees were withheld hours just so they wouldn't get full time benefits. Looking around for jobs was also difficult as most other employers did not want full time employees either.

Employers in lesser skilled fields get away with murder because employees have very little ground to stand on. They don't have the income to build financial independence, nor does the government help them out in many cases. Even unemployment is gamed and withheld.

I don't know if UBI is the answer, but something needs to be done.

I am - or at least plan to. I am writing a knowledge base, focused around a sort of mind-map of information and sources - and for each node I am adding a series of Q&As that can be used for spaced rep.

My goal is a few fold:

1. I research plenty of things in life and I need to document my findings. Not some grand importance to my "findings", merely that I've found I tend to summarize to such an extreme degree that I lose how I came to that summarization.

2. I want to remember my summarizations mentioned above.

3. I want to run a self-experiment on my .. I guess, random access memory. I tend to have terrible memory for the little random details of live these days. What was that movie name? What was that actors name? What street does X person live on? What is my wife's phone number? etc.

I never seem to run into this problem in things I "care" about, namely tech, programming and etc. But still, it bothers me how frequently I draw a blank from my memory. While I don't often see many repeats in this "random access memory" problem (aka movie names/etc), I am curious if I can improve this memory pattern by memorizing the things I so easily forget. I have no data backing it up, I'm just curious.

Why am I writing my own tool instead of Anki/etc? There's a few side features that I want to design a UX around, and see how it goes. It's all an experiment in the UX of information storage, retrieval and memorization/retention.

I'm a dev who generally dislikes design. I'm picky, I notice all the bad things, but design is simply not what I want to be working on. This offering was tempting for me.

Maybe worth noting, I did not buy it however. Namely because of how I'm writing my UIs atm. I can't use this product to quickly prototype - I'd instead have to hand copy layers of DOM elements and classes. At that point the buy-in of quick prototypes seems less valuable to me.

Still though, I'm definitely a target audience for this type of thing. Design, fiddling with the fine UI details, choosing colors, etc - all of that is not my area, nor do I desire it to be. I see the value in it.

Okay, let me ask this then - what language would be better compared to contrast the shortcomings of Go that the other takes issue with?

Certainly not C++, no?