> Git makes it easy to make copies, but its nature of having one designated "origin" remote per repository that serves as upstream source of truth (on platforms like github also across forks) makes it not really federated/decentralized the way Mastodon et al. are.
That makes sense. Each Activitypub server might also be considered the source of truth for any given post, but since you're usually going to fetch them from your own instance that your account lives on you're not getting it directly from there unless you specifically do it yourself.
> But that said, Mastodon/ActivityPub don't really feel like mature solutions yet.
Yeah, that makes sense. I think this is partly because Activitypub is both quite opinionated, but also gives you quite some wiggle room with how you implement different functionality, like defederation. And of course the most well known software in that space is effectively what all others have to follow.
Git is probably a more stable protocol, but then again ActivityPub is served over HTTP, which is also pretty stable. I believe the same issues would befall this as well, since Git, to me, doesn't seem to be the biggest factor in this, and more the append-only nature of it. I've never been a big fan of append-only social networks.
I've been running a Mastodon server for a couple of years now and have had relatively few federation issues, luckily. But I do agree that trudging through the logs and figuring out what's going on is not exactly ideal, not to mention debugging other issues like if something went wrong during the key exchange with your server and a remote one, or if you accidentally lose your key and suddenly can't talk to any other instance since they won't trust your old domain with the new key. But you might run into similar issues with this, right?
Edit: If it came across as downplaying the project or it's author then that wasn't my intention at all. These were just some thoughts that immediately popped into my head when I saw this. They may well have thought through answers to my not thought through questions, and I certainly don't mean to pretend like I know better.
I'm sorry but I believe I'm missing something here. How does this solve any of the problems that people commonly have with decentralized, federated social networks?
* You're still either hosting your own, or at the whim of whomever hosts your repository. Mastodon.social or GitHub.
* Hosting your own Git is not particularly easier than hosting your own GoTo Social or Akkoma.
* What if you end up with either a big following, or a big follower list? Aren't you going to be rate limited by GitHub?
* Is signing up for GitHub easier than signing up for mastodon.social, especially if Mastodon et al already have good mobile clients?
* What about moderation?
* What about media?
And I mean... Isn't Git federated by nature? Multiple machines store multiple copies of the data. That's defederation isn't it?
But OK, let's put the federated social networks we do have aside for a moment.
The site says: Every user stores their application state in a git repo they own and control.
But you don't do that if you're on GitHub, right? Not really, anyway. What is the benefit from doing this over git? What if I want to delete something? What is the overhead of the git protocol?
If it's just a toy, then that's totally cool with me. But it says that Microsoft Research is involved. I'm a bit confused. What is this?
That site really doesn't play well with screen readers. When I clicked the link for the first time I was severely confused. I had to come back here to read that I had to scroll, and when I did, sometimes some new text showed up, and other times it didn't.
This is just an observation. I understand that some people love making lovely things, and that sometimes those things are at odds with being accessible to some people. But this is a real world example where I cannot access a restaurant website, even if the restaurant hasn't opened yet. So even now I'm still confused as to what's actually going on there.
This seems to be more and more of a problem recently. I initially got a Macbook to be able to publish apps to the App Store, but I quickly got frustrated and now lost all motivation I ever had. If people ask why I'm usually in favor of web apps wherever possible, especially with modern web APIs, it's because of needless and unnecessary problems like these. I use an iPhone because of accessibility reasons. So in order to be able to use what I make on my own devices, I'd rather just make it a web app. Luckily we're getting push notifications for PWA's soon so at least there's that...
Someone please explain. There are a lot of people who hate on Zig in this thread and say "why not Rust". Then someone comes in and says "Hey, I like C" and gets summarily attacked for that opinion. But it's the same in Rust threads, too. Someone always comes in and says "Ugh, not another Rust thread". And it's been getting worse.
It's to the point where I usually don't even bother reading the comments on programming language specific submissions anymore. It's highly predictable and it's quite tiring to read.
Everyone who does that is saying "My language is better than yours", and in the same breath criticizing someone else for thinking that, in fact, their language is better. When we all know neither is. It's different tradeoffs, different concepts from different times perhaps, or just different goals.
So what if someone wants to use Zig for their native Ruby modules? So what if someone wants to write their Python extension in Rust? So what if someone doesn't mind D's GC?
Instead of immediately attacking them for their choice of language, or excusing it by saying "Those people can't be helped", maybe we can listen instead. Saying someone's a lost cause is never nice. And maybe you'll realize that you have a bias too. And that people might disagree with it.
We'll get nowhere if we just scoff at everybody. There are good projects made in all kinds of different programming languages, and nobody is lesser for choosing a different one than you'd want them to. Instead of a nice discussion about native ruby modules or addons and a healthy discussion about doing that in Zig, or Rust, or C, or Crystal, or whatever, it's just about the languages themselves again and how people are wrong for using them.
Randomly, I get locked out of my Protonmail webmail interface by an hCaptcha.
This in itself isn't a problem. The problem starts because I can't actually see the captcha images. So in order to get at my email, I have to provide hCaptcha with a third party email which isn't protonmail, and enable third party cookies and/or install a browser extension for them to set an "accessibility cookie" to get past the captcha.
And, well, nobody wants to do anything about that either. I'm sorry, but that doesn't seem reasonable to me.
I feel like I should preemptively apologize and I'm really not trying to knock the project in any way, and the achievement is pretty epic, but those who have seen my username on this site before know what's coming, especially in regards to people seriously considering using WX Widgets on the web...
This app is inaccessible. Audacity on its own is already a bit difficult to use with a screen reader, but sadly, this port, unsurprisingly, is even worse. I've managed to at least explore some of the UI using OCR, but it was very cumbersome and I could never get it to do what I wanted.
Just uttering my careful warning that you should please, please, please think 3, 4, 5 times before deciding to actually use this UI library for serious projects. The benefits of using what the browser already gives you is that, if you're not going too crazy, accessibility comes for free and there's very little you need to do to make sure that we can still use your app.
Again, I understand that this is a port of Audacity, and I believe that what we can do in browsers is pretty amazing and my aim is not to discourage anyone from trying out new things. I'm just saying that this app is 100% screen reader inaccessible so please make sure you have a valid reason for keeping out users with disabilities (hint, you almost never do) by using WX widgets drawn directly to a canvas. And if you do, please think hard about what you can do to still keep your app accessible. I'm sure there are ways to add accessibility to a web port of WX, but if you can, sticking with the things the browsers give you is usually the better idea.
Add accessibility to that list. Screen readers, magnifiers, switch controls, etc. Usually game engines don't support these while your native OS UI probably does, and the web is also not bad in that regard.
As expected, same problem as all the other UI toolkits. Tried several of their apps, was able to use none of them with a screen reader or other accessibility tools. It's nice if you draw the UI directly to the screen, but you skip a lot of steps that OS vendors took to make sure your app can be used by as many people as possible. So always keep that in mind if you're going to use any of these GUI toolkits for your own project!
I don't have much experience with XCode, however the few things I did do seemed accessible. As accessible as XCode can be - I personally find a lot of the interface a bit confusing. Super long lists, nested options, but I assume those aren't things that are specifically confusing to people using assistive tech and I'm sure I'd be able to find my way around it well if I used it more. Mac seems to be a lot more consistent with their accessibility story than others, and we constantly get new features from them. With the new MacOS for example we got a VoiceOver feature that tells us when we have formatting problems in text, and we can finally get indentation announced (something which we had to do using custom scripting before).
Not to mention all the cool things that involve some form of (live) image recognition, like telling us where people are, where doors are, etc etc.
> The same way you don't start a saas app with localization from day one.
Believe it or not, my native language isn't English, so this doesn't make sense to me.
> I'm not blind so for sure I won't really care about accessibility
You should. You're not blind yet. You're not deaf yet. You don't have motor control problems yet. It does not take much to get there. One small accident and your life is changed forever. It's terrifying.
> why not use an ide developed for blind people instead of using the same as non blind people?
Because not only do those not exist, but that seems just a bit silly to me. Most operating systems provide pretty good means to make apps accessible. They usually have API's that, if implemented, will make your app work with whatever assistive tech you may use on that platform. Most apps work on Mac, most apps work on Windows. Linux is sadly another story, but even there we can at least edit text.
What about tutorials? Courses? If we can't use the same software, should we also not be able to do any of them? Should we be locked out of great innovation because we need special software that nobody wants to update? Or worse, locked to one specific platform?
I believe I've said this before, but as sad as it is, every time I hear "Custom UI" I immediately think "Oh great, this won't work". In fact, I'm much more likely to give something a go if it's developed using web technologies. While not perfect, at least I know that there's a chance that it might work. It shouldn't be like that.
My favorite is VS Code by far. I use it daily. They recently also added a bunch of sound cues to help figure out if code is folded or a line contains an error. It's pretty great.
Auto completion reads well, the parameter hints read, even the built-in terminal works. So overall I'm really happy with it.
Please don't forget about accessibility. Getting this right from day 1 will make your life a lot easier in the long run. If I remember correctly, I was never able to use Atom with a screen reader. Hearing custom UI already makes me nervous and I'm pretty sure I won't be able to use Zed with a screen reader either.
Blind developers exist. Please don't forget about us. It's one of the few areas where we can actually make a meaningful difference together with our peers on an equal playing field.
I'm not trying to defend Mark here, but it does bother me slightly that people continuously bring up that really old quote of his from many years ago. People change. I've said some disagreeable things on chat many years ago as well. Maybe as a joke, maybe I was frustrated, but I do regret them and I've since grown as a person. I would hate it if someone kept rehashing something I said ages ago to further their narrative of me. Would it not make sense to judge a person by what they're doing now rather than what they did in college? What about you? Have you never made dumb comments that you really wish you hadn't? What if those kept getting brought up against you now rather than who you've become since then? Just a thought.
> In fact (as I'm sure you know), one of the most beloved speech synthesizers among English-speaking blind users is a closed-source product called ETI-Eloquence that has been basically dead for nearly 20 years.
This is exactly the speech synthesizer I use daily. I've gotten so used to it over the years that switching away from it is painful.
On Apple platforms, though, using it is not an option. So I use Karen. Used to use Alex, but Karen appears to be slightly more responsive and tries to do less human stuff when reading. Responsiveness is a very important factor, actually. Probably more so than people might realize. Eloquence and ESpeak react pretty much instantly whereas other voices might take 100 MS or so. This is a very big deal for me. Just like how one would like instant visual feedback on their screen, it's the same for me with speech. The less latency, the better.
My problem with ESpeak is that it sounds very rough and metallic whereas Eloquence has a much warmer sound to it. I pitch mine down slightly to get an even warmer sound. Being pleasant on the ears is super important if you listen to the thing many, many hours a day.
I thought I'd just add another fun fact/data point here. This is obviously my personal opinion. I have to use TTS to use my computer with a screen reader, and for that, I mostly prefer more synthetic speech. When I read long form text like books, articles, etc. I do prefer more natural voices, but for doing actual work like reading code or simply using user interfaces, I like the predictability of more synthetic/algorithmic speech. Apple added the neural Siri voices to the new VoiceOver. They sound incredible but the quality of the voice also brings latency with it. Something like ESpeak is much, much more performant and predictable, and it speeds up much better. I use my TTS at a very fast rate and I find that the more natural a voice, the harder it is to understand at that speech rate. Neural voices speak the same phrase of text differently every time it's uttered. Slightly different intonation, slightly different speech rhythm. This makes it hard to listen out for patterns. So for me there's definitely still a place for synthetic speech.
Something that Chromium apps do give you however, for free for the most part, is accessibility. I just tried the GUI version of this client and was not surprised to find out that I could not use it.
The new Spotify UI released a few months ago is the most accessible Spotify has ever been. Landmarks, clear labels, headings, and even aria-trickery to automatically announce things using my screen reader. I remember being very frustrated with the old UI's to the point where I chose another service just because it was more accessible, even if it didn't have a desktop app. YouTube Music and Deezer had much better UI's from the get go.
At this point, I'm almost happy to see an Electron app. It doesn't guarantee accessibility, but the likelyhood is so, so, so much higher than any modern cross-platform UI framework.
I'd almost go as far as to not call these UI's native. Because if they were, if they used native controls, the accessibility would be there. The OS vendors spend a lot of time to make them usable and consistent. Sadly, these UI frameworks don't, or can't.
Sure, psst has a CLI, but I only get panics. I can't do -h to find out what I can do with it, I can only call it with a spotify URL and get it to play and exit once it's done. It feels like the cli was included as a sort of testing tool to check the underlying libs and code, and not as a usable version of the app itself - but it's still very early in development so the GUI might be the same. I can't tell.
I know that this project is still in very early stages, however as I often do, I've come here to mention accessibility. I've run the examples on both Mac and Windows, and as expected, I can't use either of them. This is not a strict criticism yet and I'm aware how difficult it is to interface with accessibility API's, but I do hope that if this project does make it far enough that this will be considered. Pretty much everything that draws their UI directly to the screen using OpenGL or similar immediately makes me think that I probably don't even need to try the program to know that it's inaccessible, and more often than not I'm right. If you're building an app using these gui toolkits, please do keep this in mind.
I know I do almost nothing on HN but complain about accessibility, but it's really important to me because, well, that's how I uze my tech. And so far, sadly, Flutter hasn't impressed either with its previous versions. Edit boxes in particular were a major pain point, and things like you're describing were also less than optimal. I never knew where the focus was and what it was doing. With broken markup there was at least ways around it. But I'm scared of things that render on the canvas. Most browsers actually get this right and have support for these things that don't require ugly hacks if you use the DOM. And there is no real way to interface with assistive tech from JavaScript except through it. So you have to somehow still actually represent your apps UI in the Dom in some way.
Yes. My screen reader, at least Voiceover on my phone, had a stroke reading that. I had to navigate letter by letter and guess what it meant. But it's also quite common so I'm used to doing that regardless.
It works surprisingly well, however it quickly falls apart if nonstandard controls are introduced. If you have a custom control that does not behave at all like a standard control would, you'll quickly see its limits. It's OCR is also pretty good, but errors do still happen which make apps unusable. Don't get me wrong, it is actually amazing and works much better than I expected, but it's obviously no match for a proper implementation.
It's not like most of us are completely helpless when it comes to crossing streets. We know when it might be unsafe, and if a bus is approaching and you tell me to go, I wouldn't. But it might help a lot to actually reach the right street/find the second inaccessible traffic light/etc. You could also make sure that you describe the potential route to be taken, which might make it safer still. Sometimes a "A little left" or "You're turning onto another road" can be very helpful, which I assume was more or less the case. :)
Their accessibility mode is "Give us your email and we'll probably think you're a human for a while... until we don't and make you use privacy pass... until we take away your tokens because yeah you're absolutely a bot.". yeah... no. Absolutely not. Also that thing doesn't work with incognito, nor vpn's/tor/whatever. I've stopped trying to bother with numerous sites, all running behind Cloudflare, for exactly this reason.