Notices by arcanicanis (arcanicanis@were.social), page 8

Protip: If you have the LUKS/dm-crypt tools installed, there is a benchmark tool that comes with it for checking your performance of different algorithms per the Linux kernel crypto API, by simply invoking cryptsetup benchmark. I just wish it also benchmarked some newer ciphers as well, like those used in WireGuard. Some examples of numbers:

Intel(R) Celeron(R) 2955U @ 1.40GHz (no AES extension support):

AMD Ryzen 5 5600X 6-Core Processor (aes and vaes extensions):

SiFive Freedom U740 (HiFive Unmatched; no AES extensions):

I strongly disagree because Fidonet and E-mail don’t need to teach its users they’re not centralized. The UX and UI don’t need to explanation it for users to use it effectively.

For email, it’s because it’s commonplace, as many are even growing up in an environment where email has existed as a norm before they were born, as people have to understand email for some work environments, or for even getting a job. I don’t think that people think much on how email works, of knowing that it’s a federated protocol, just merely “that’s the way it works”. Hell, majority of people likely don’t even configure their own email client themself, they likely just use the vendor’s application instead.

Nonetheless, federated content platforms are an emerging thing, and thus people have to ‘re-learn’ that there are different ways to intercommunicate than email.

Technically speaking, don’t even need to do that. Just have generic specific agreed upon webpage domain for this. Phones apps can intercept that URL, non-app aware browsers landing on that page (…)

It’s been at least 6 years since I last touched mobile app dev. Last I remember it was an ‘Android thing’ to ‘intercept’ certain registered URLs to a mobile app, whereas I think the iOS way was only with registering custom URI schemes. It may be a big risk to trust one entity to host said address, unless they’re someone universally trusted and heavyweight enough to keep it up for near-eternity. The “Web-based protocol handler” would be a ‘web native’ way of handling it, without requiring any installed app. In fact, it can be both: if there’s registered handler for ‘web+activitypub’ (for example), it could present that URL, if not, then present the landing page handler (which Android clients could intercept and handle).

…A delete & redraft later: it would be nice if Soapbox had a Markdown preview… and not forget that a post was set to Markdown syntax, when delete and redrafting (which gets unset).

I strongly disagree because Fidonet and E-mail don’t need to teach its users they’re not centralized. The UX and UI don’t need to explanation it for users to use it effectively. For email, it’s because it’s commonplace, as many are even growing up in an environment where email has existed as a norm before they were born, as people have to understand email for some work environments, or for even getting a job. I don’t think that people think much on how email works, of knowing that it’s a federated protocol, just merely “that’s the way it works”. Hell, majority of people likely don’t even configure their own email client themself, they likely just use the vendor’s application instead. Nonetheless, federated content platforms are an emerging thing, and thus people have to ‘re-learn’ that there are different ways to intercommunicate than email.

Technically speaking, don’t even need to do that. Just have generic specific agreed upon webpage domain for this. Phones apps can intercept that URL, non-app aware browsers landing on that page (…) It’s been at least 6 years since I last touched mobile app dev. Last I remember it was an ‘Android thing’ to ‘intercept’ certain registered URLs to a mobile app, whereas I think the iOS way was only with registering custom URI schemes. It may be a big risk to trust one entity to host said address, unless they’re someone universally trusted and heavyweight enough to keep it up for near-eternity. The “Web-based protocol handler” would be a ‘web native’ way of handling it, without requiring any installed app. In fact, it can be both: if there’s registered handler for ‘web+activitypub’ (for example), it could present that URL, if not, then present the landing page handler (which Android clients could intercept and handle).

Item Get sound https://www.macincloud.com/

I don’t know if their pricing structure has changed a lot since, but I had used this service in the past when trying to get something published in the iOS App Store, or in the Apple Books store thing, for a client.

Last it was just fill up $30 of credits or so, and get billed $1/hr out of the credit for how long you’re logged in.

I have a lot of gripes in my past experiences of the iOS/macOS ecosystem, especially with ebooks and them trying to make you author it only in their macOS desktop app, for something that’s effectively just an ePub creator with proprietary extensions. You can’t even upload the ePub on the web management portal, it has to be done through the macOS application, which brings you to the web portal for the rest.

But yes, I also used it for iOS app dev and publishing. Last time I did, it was $100/year just to even have a developer account, but allegedly that may be waived now. Also you had to have the serial number (or whichever) of an iPhone registered to the developer account, even though you have a full iOS emulator in Xcode. It didn’t even matter if you actually launched it on that iPhone or not, just merely that it was registered that you allegedly have hardware.

Oh boy, and review process–that’s another story.