There are a couple I have in mind. Like many techies, I am a huge fan of RSS for content distribution and XMPP for federated communication.
The really niche one I like is S-expressions as a data format and configuration in place of json, yaml, toml, etc.
I am a big fan of Plaintext formats, although I wish markdown had a few more features like tables.
GRPC for building APIs instead of REST. Type safety makes life easier
I mean, REST-ful JSON APIs can be perfectly type-safe, if their developers actually take care to make them that way. And the self-descriptive nature of JSON is arguably a benefit in really large public-facing APIs. But yeah, gRPC forces a certain amount of type-safety and version control, and gRPC with protobuf is SUCH a pleasure to work with.
Give it time, though, it’s definitely gaining traction.
The biggest problems with gRPC are:
- Very complicated. Way more complexity than you want in most cases.
- Depends on HTTP 2. I’ve seen people who weren’t even doing web stuff reach for gRPC, and now boom you have a web server in your stack for now reason. Compare to Thrift which properly separates out encodings, transports, etc.
- Doesn’t work from the web. There are actually two modifications to gRPC to make it work on the web which means you have three different incompatible versions of gRPC with different feature sets. IIRC some of them require setting up complex proxies, some don’t support streaming calls, ugh. Total mess.
Plain HTTP can be type safe. Just publish JSON schema or Typespec files or even use Protobuf.
Depends on HTTP 2.
Doesn’t work from the web.
Am I the only one who is weirded out? Requiring a web server for something and then requiring another server if you want it to actually work on the web?
How expensive do people want to make their deployments?Your concerns are all valid, but about 1 and 3 there are possible solutions. I’m using Rust+Tonic to build an API and that’s eliminate the necessity of proxies and it’s very simple to use.
I know that it don’t solve all problems, but IMHO is a question of adoption. Easier
toldtools will be develop for it.
I like the concept and I think the use case is almost covered by generating API client through generated OpenAPI spec.
It’s needs a bit of setup but a client library can be built whenever a backend server is built.
It’s the recommended approach to replace WCF which was deprecated after .NET framework 4.8. My company is just now getting around to ripping out all their WCF stuff and putting in gRPC. REST interfaces were always a non-starter because of how “heavyweight” they were for our use case (data collection from industrial devices which are themselves data collectors).
i’m a plan 9 from bell labs fan. Imagine how excited I was when wsl used 9P for its plumbing. then they scrapped it all for wsl2.
just, the power they managed to get out of those union mounts… your application wants access to the mouse? sure, here’s a file named “mouse”. it’s got the coordinates in it. you want to draw to the screen? here’s a file called like “bitmap” or whatever, just write to it. you want to start a process on another machine? just cd to it and start the process there. want to have the UI show up on your machine? symlink your bitmap file to that directory.
I also wish early web composability could have stayed and expanded. like, the old vlc embed player, which would just show up in your browser and could play any file inline? great stuff. Imagine if every application composed with everything else, like the android Activity and Intent concepts but for anything, just by virtue of living in the same os. need an image? just ask the os and it will present the user with many ways to procure an image, let the selected one run , and hand you back an image. you don’t even have to care where from. in a way, it’s what the arcan guy is doing with his experiments, although that’s more for stitching together graphical pipelines.
Plan 9 even extended the “everything is a file” philosophy to networking, unlike everybody else that used sockets instead.
Are sockets not files?
They’re “file like” in the sense that they’re exposed as an
fd, but they’re not exposed via the filesystem at all (Unlike e.g. unix sockets), and the existing API is just mapped over the sockets one (i.e.write()instead ofsend(),read()instead ofrecv()). There’s also a difference in how you create them, youopen()a file, butconnect()a socket, etc.(As an aside, it turns out Bash has its own virtual file-based wrapper around sockets, so you can do things like
cata remote port with Bash, something you can do natively in Plan 9)Really it just shows that “everything is a file” didn’t stand up in practice, there’s more stuff that needs special treatment than doesn’t (e.g. Interacting with TTYs also has special APIs). It makes more sense to have a better dedicated API than a generic catch-all one.
ISO 8601 date format. Not because it’s from a standards body, but because it’s simple, sensible, clearly defined, easy to recognize, and very effective.
Date field placement in any order other than most-significant-digits-first is not only counterintuitive, but needlessly complicated to work with. Omitting critical information like the century is ambiguous and confusing.
We don’t live in isolated villages any more. Mixing and matching those problems by accepting all the world’s various regional and personal date styles, especially with no reliable indication of which ones apply in any given case, leads to the hodgepodge of error-prone date madness that we have today.
The 2024-09-02 format should be taught in schools and required in official documents. Let the antiquated date styles fall into disuse outside of art and personal correspondence, like cursive writing.
And it can be sorted alphabetically in all software. That’s a pretty big advantage when handling files on a computer
For the newbies: RFC 3339 vs ISO 8601. Bookmark this site.
That looks like an interesting diagram, but the text in it renders too small to read easily on the screen I’m using, and trying to open it leads to a javascript complaint and a redirect that activates before I can click to allow javascript. If it’s yours, you might want to look in to that.
The table below works, though. Thanks for the link.
Alas it’s not my site (and I think it’s meant to be read on a desktop screen), so I can’t fix it.
7 digit years feels way to optimistic, but I’ll be rooting for us.
RFC 3339 is a simplified profile of 8601 that only covers YYYY-MM-DD style formatting, if you only ever use that format and avoid the things like “2024-W36” they’re mostly interchangeable.
The week-of-year is far more relevant in Western Europe, and is used quite a bit in business. I have a Junghans watch that has a week complication.
It’s an important format outside of the US, and gives ISO-8601 an edge as a standard of conformance.
I arrived to manage releases in a company, the previous manager named releases as “release04092016”, as USA standard. My first recommendation was to name releases as “releaseyyyymmdd” so “release20160409”. I was asked by another manager why to change that, so I showed her a sorted list of releases “git branches” and asked her, can you tell me there when was the last release? (a very common question) Of course, to find the last release you need to check the whole list because the mmddyyyy order is useless. The answer with yyyymmdd was immediate, just look at the last row.
Some countries already use it officially too :)
I had the fortune of being hired to build up from zero my department, and one of the first “rules” I made was all dates are ISO-8601 and now every process runs with 8601, if you use anything different your code is going to fail eventually when it finds another column date in 8601.
The year is the information that most of the time is the least significant in a date, in day to day use.
DDMMYY is perfect for daily usage.
Your day to day use isn’t everyone else’s. We use times for a lot more than “I wonder what day it is today.” When it comes to recording events, or planning future events, pretty much everyone needs to include the year. Getting things wrong by a single digit is presented exactly in order of significance in YYYY-MM-DD.
And no matter what, the first digit of a two-digit day or two-digit month is still more significant in a mathematical sense, even if you think that you’re more likely to need the day or the month. The 15th of May is only one digit off of the 5th of May, but that first digit in a DD/MM format is more significant in a mathematical sense and less likely to change on a day to day basis.
For any scheduled date it is irrelevant if you miss it for a day, a month or a year. So from that perspective every part of it is exactly the same, if the date is wrong then it is wrong. You say that it is sorted in the order of most significants, so for a date it is more significant if it happend 1024, 2024 or 9024? That may be relevant for historical or scientific purposes but not much people need that kind of precision. Most people use calendars for stuff days or month ahead or below, not years or decades.
If I get my tax bill, I don’t care for the year in the date because I know that the government wants the money this year not next or on ten. If I have a job interview, I don’t care for the year, the day and months is what is relevant. It has a reason why the year is often removed completely when dates are noted or made. Because it Is obvious.
Yes I can see why YYYY-MM-DD is nice for stuff like archiving purposes, it makes sorting and grouping very easy but there they already use the best system for the job.
For digital documents I would say that date and time information should be stored in a defined computer readable standard so that the document viewer can render or use it in any way needed. That could be swatch internet time as far as I care because hopefully I would never look at the raw data at all.
You say that it is sorted in the order of most significants, so for a date it is more significant if it happend 1024, 2024 or 9024?
Most significant to least significant digit has a strict mathematical definition, that you don’t seem to be following, and applies to all numbers, not just numerical representations of dates.
And most importantly, the YYYY-MM-DD format is extensible into hh:mm:as too, within the same schema, out to the level of precision appropriate for the context. I can identify a specific year when the month doesn’t matter, a specific month when the day doesn’t matter, a specific day when the hour doesn’t matter, and on down to minutes, seconds, and decimal portions of seconds to whatever precision I’d like.
Ok, then I am sure we will all be using that very soon, because abstract mathematic definitions always map perfectly onto real world usage and needs.
It is not that I don’t follow the mathematic definition of significance, it is just invalid for the view and scope of the argument that I make.
YYYY-MM-DD is great for official documents but not for common use. People will always trade precision for ease of use, and that will never change. And in most cases the year is not relevant at all so people will omit it. Other big issue: People tend to write like they talk and (as far as I know) nobody says the year first. That’s exactly why we have DD-MM and MM-DD
YYYY-MM-DD will only work in enforced environments like official documents or workspaces, because everywhere else people will use shortcuts. And even the best mathematic definition of the world will not change that.
DDMMYY is perfect for daily usage.
Except that DDMMYY has the huge ambiguity issue of people potentially interpreting it as MMDDYY. And it’s not straight sortable.
My team switched to using YYYY-MM-DD in all our inner communication and documents. The “daily date use” is not the issue you think it is.
Except that DDMMYY has the huge ambiguity issue of people potentially interpreting it as MMDDYY.
Yes and YYYY-MM-DD can potentially be interpreted as YYYY-DD-MM. So that is an zero argument.
I never said that the date format should never used, just that significants is a arbitrary value, what significant means depends on the context. If YYYY-MM-DD would be so great in everyday use then more or even most people would use it, because people, in general, tend to do things that make their life easier.
There is no superior date format, there are just date format that are better for specific use cases.
My team switched to using YYYY-MM-DD in all our inner communication and documents
That is great for your team, but I don’t think that your team has a size large enough to have any kind of statistically relevance at all. So it is a great example for a specific use case but not an argument for general use at all.
Yes and YYYY-MM-DD can potentially be interpreted as YYYY-DD-MM. So that is an zero argument.
No country uses “year day month” ordered dates as standard. "Month day year, " on the other hand, has huge use. It’s the conventions that cause the potential for ambiguity and confusion.
That is great for your team, but I don’t think that your team has a size large enough to have any kind of statistically relevance at all. So it is a great example for a specific use case but not an argument for general use at all.
Entire countries, like China, Japan, Korea, etc., use YYYY-MM-DD as their date standard already.
My point was that once you adjust, it actually isn’t painful to use as it first appears it could be, and has great advantages. I didn’t say there wasn’t an adjustment hurdle that many people would bawk at.
https://en.m.wikipedia.org/wiki/List_of_date_formats_by_country
Entire countries, like China, Japan, Korea, etc., use YYYY-MM-DD as their date standard already.
And every person in those countries uses YYYY-MM-DD always in their day to day communication? I really doubt that. I am sure even in those countries most people will still use short forms in different formats.
Yes, and their shorthand versions, like writing 9/4, have the same problem of being ambiguous.
You keep missing the point and moving the goal posts, so I’ll just politely exit here and wish you well. Peace.
I never moved the goalposts, all I always said was that a forced and clunky date format like YYYY-MM-DD will never find broad use or acceptance in the major population of the world. It is not made for easy day to day use.
If it sounded like I moved goalposts, that maybe due to english as a second language. Sorry for that.
But yes, I think we both have made our positions and statements clear, and there is not really a common ground for us. Not because one of us would be right or wrong but because we are not talking about the topic on the same level of abstraction. I talk about it from a social, very down to the ground perspective and you are at least 2 levels of abstraction above that. Nothing wrong with that but we just don’t see the same picture.
And yes using YYYY-MM-DD would be great, I don’t say anything against that on a general level, I just don’t ever see any chance for it used commonly.
So thank you for the great discussion and have a nice day.
Also, you can sort by ascending file names
I love this standard. If you dig deeper into it, the standard also covers a way to express intervals and periods. E.g. “P1Y2M10DT2H30M” represents one year, 2 months, 10 days, 2 hours and 30 mins.
I recall once using the standard when writing a cron-style scheduler.
I also like the POSIX “seconds since 1970” standard, but I feel that should only be used in RAM when performing operations (time differences in timers etc.). It irks me when it’s used for serialising to text/JSON/XML/CSV.
Also: Does Excel recognise a full ISO8601 timestamp yet?
I also like the POSIX “seconds since 1970” standard, but I feel that should only be used in RAM when performing operations (time differences in timers etc.). It irks me when it’s used for serialising to text/JSON/XML/CSV.
I’ve seen bugs where programmers tried to represent date in epoch time in seconds or milliseconds in json. So something like “pay date” would be presented by a timestamp, and would get off-by-one errors because whatever time library the programmer was using would do time zone conversions on a timestamp then truncate the date portion.
If the programmer used ISO 8601 style formatting, I don’t think they would have included the timepart and the bug could have been avoided.
Use dates when you need dates and timestamps when you need timestamps!
Thats an issue with the time library, not with timestamps. Actually timestamps are always in UTC, you need to do the conversion to your local time when displaying the value. There should be no possible off-by-one errors, unless you are doing something really wrong.
ISO 216 paper sizes work like this: https://www.printed.com/blog/paper-size-guide/
It’s so fucking neat and intuitive! How is it not used more???
sorry to tell you this bud…
Clearly the rest of the world are communists! It’s not us, it’s you! I’m not crying you’re crying! 😭😭😭
It’s also worth noting that switching from ANSI to ISO 216 paper would not be a substantial physical undertaking, as the short-side of even-numbered ISO 216 paper (eg A2, A4, A6, etc) is narrower than for ANSI equivalents. And for the odd-numbered sizes, I’ve seen Tabloid-size printers in America which generously accommodate A3.
For comparison, the standard “Letter” paper size (aka ANSI A) is 8.5 inches by 11 inches. (note: I’m sticking with American units because I hope Americans read this). Whereas the similar A4 paper size is 8.3 inches by 11.7 inches. Unless you have the rare, oddball printer which takes paper long-edge first, this means all domestic and small-business printers could start printing A4 today.
In fact, for businesses with an excess stock of company-labeled #10 envelopes – a common size of envelope, measuring 4.125 inches by 9.5 inches – a sheet of A4 folded into thirds will still (just barely) fit. Although this would require precision folding, that’s no problem for automated letter mailing systems. Note that the common #9 envelope (3.875 inches by 8.875 inches) used for return envelopes will not fit an A4 sheet folded in thirds. It would be advisable to switch entirely to A series paper and C series envelopes at the same time.
Confusingly, North America has an A-series of envelopes, which bear no relation to the ISO 216 paper series. Fortunately, the overlap is only for the less-common A2, A6, and A7.
TL;DR: bring reams of A4 to the USA and we can use it. And Tabloid-size printers often accept A3.
My printer will print and scan any A side paper. But I can’t even buy A paper! Fucking America
Presumably you could just buy that paper size? They’re pretty similar sizes; printers all support both sizes. I’ve never had an issue printing a US Letter sized PDF (which I assume I have done).
Kind of weird that you guys stick to US Letter when switching would be zero effort. I guess to be fair there aren’t really any practical benefits either.
I’ve literally never even seen A paper in America. Probably would have to special order it from another country
Ah fair enough.
I mean I’d love to use it. Of course America is behind the times of civilized nations.
Also, A4 simply has a better ratio than letter. Letter is too wide, making A4 better to hold and it fits more lines per page.
Most preschool kids know what an A4 sheet is. Not sure how it can be used more.
Alright, but seriously: IPv6.
AV1 video codec !
I’ll add JXL if we’re doing codecs
ActivityPub :) People spend an incredible amount of time on social media—whether it be Facebook, Instagram, Twitter/X, TikTok, and YouTube—so it’d be nice to liberate that.
I mean, you’re in the right place to advocate for that 😜
SqLite for office formats.
I’m not quite following this. Can you please elaborate?
I read this somewhere. Since i didn’t find it anymore and don’t remember all the advantages aside from concurrence (don’t have to unpack a zip archive) i asked chatgpt:
Using SQLite instead of ZIP for office formats can offer several advantages, particularly in terms of data management, performance, and functionality. Here are some key benefits:
- Structured Data Storage: SQLite is a relational database management system, which means it can store data in a structured format with relationships between different data entities. This allows for more complex data queries and relationships compared to a flat ZIP file structure.
Query Capabilities: With SQLite, you can use SQL queries to retrieve and manipulate data efficiently. This is particularly useful for applications that require complex data retrieval, filtering, and aggregation, which would be cumbersome with a ZIP file.
Integration with Other Tools: SQLite can be easily integrated with various programming languages and tools, making it a versatile choice for applications that require data storage and manipulation.
- Concurrency: SQLite supports multiple readers and a single writer, allowing for better concurrency when accessing and modifying data. This can be beneficial in collaborative environments where multiple users may need to access or update the data simultaneously.
- Data Integrity: SQLite provides features like transactions, which ensure that a series of operations either complete successfully or leave the database unchanged. This helps maintain data integrity, especially in scenarios where multiple operations are performed.
- Ease of Updates: Updating specific pieces of data in an SQLite database can be more efficient than modifying a ZIP file, which may require decompressing, altering, and recompressing the entire file.
- Reduced File Size: While ZIP files compress data, SQLite can store data in a more compact format, especially for structured data. This can lead to smaller file sizes for certain types of data. Built-in Data Types: SQLite supports various data types (e.g., INTEGER, TEXT, BLOB), which can be beneficial for storing different kinds of data in a more organized manner compared to the generic binary format of ZIP files.
- Versioning and History: SQLite can be used to implement versioning and history tracking for documents, allowing users to maintain a history of changes and revert to previous versions if necessary.
I put related points together. One point was moot, removed.
- Structured Data Storage: SQLite is a relational database management system, which means it can store data in a structured format with relationships between different data entities. This allows for more complex data queries and relationships compared to a flat ZIP file structure.
Unicode editors for notes/todo formats, making markup unnecessary.
Does unicode have bold/italics/underline/headings/tables/…etc.? Isn’t that outside of its intended goal? If not, how is markup unnecessary?
Does unicode have bold/italics/underline/headings/tables/
Yes, and even 𝓈𝓉𝓊𝒻𝒻 𝕝𝕚𝕜𝕖 🅣🅷🅘🆂. And table lines & edges & co. are even already in ASCII.
Isn’t that outside of its intended goal?
🤷<- this emoji has at least 6 color variants and 3 genders.
If not, how is markup unnecessary?
Because the editor could place a 𝗯𝗼𝗹𝗱 instead of a **bold**, which is a best-case-scenario with markdown support btw. And i just had to escspe the stars, which is a problem that native unicode doesn’t pose.
What about people who prefer to type
**bold**rather than type a word, highlight it, and find the Bold option in whichever textbox editor they happen to be using?Which is what i ask for, better (or at all) support for unicode character variations, including soft keyboards.
Imagine, there was a switch for bold, cursive, etc on your phone keyboard, why would you want to type markup?
And nobody would take**bold**away, if you want to write that.Would you have to do that for every letter? I suppose a “bold-on/bold-off” character combination would be better/easier, and then you could combine multiple styles without multiplying the number of glyphs by some ridiculous number.
Anyways, because markup is already standardized, mostly. Having both unicode and markup would be a nightmare. More complicated markup (bulleted lists, tables) is simpler than it would be in Unicode. And markup is outside of Unicode’s intended purpose, which is to have a collection of every glyph. Styling is separate from glyphs, and has been for a long time, for good reason. Fonts, bold/italics/underline/strikethrough, color, tables and lists, headings, font size, etc. are simply not something Unicode is designed to handle.
Would you have to do that for every letter? I suppose a “bold-on/bold-off” character combination would be better/easier,
Yeah, had the same thought, edited already.
I don’t like that approach. Text search won’t find all the different possible Unicode representations.
You always find some excuses, huh? That would be a bug.
Always? That’s my first reply. Bug of what? A flaired character has a different code than a standard one, so your files would be incompatible with any established tools like find or grep.
About s-expressions, what i read about it: https://web.archive.org/web/20120206034439/https://shinkirou.org/blog/2010/06/s-expressions-the-fat-free-alternative-to-json/
Seems rather niche, for non-key-value-pair data structures (aren’t no-sql databases good for that?), considering that lightweight markup fulfills that role for readable document source.
S-expressions are basically directly writing the AST a compiler would normally generate. They can be extremely flexible. M-expressions were supposed to be programming part of Lisp, and S-expressions the data part. Lisp programmers noticed that code is just another kind of data to be manipulated and then only used S-expressions.
Logo is arguably a Lisp with M-expressions. But whatever niche Logo had is taken by Python now.
The appeal for json and yaml is readability, and partially ease of parsing. I say s-expressions win over both in both aspects.
Can you please expand on your references to no-sql and your reference to “lightweight markup”? I don’t quite understand what you meant there.
I’d like something akin to XML DOM for config files, but not XML.
The one benefit of binary config (like the Windows Registry) is that you can make a change programmatically without too many hoops. With text files, you have a couple of choices for programmatic changes:
- Don’t
- Parse it, make the change, and rewrite it (clobbering comments and whitespace that the user setup; IIRC, npm does this)
- Have some kind of block that says “things below this line were automatically set and shouldn’t be touched” (Klipper does this)
- Have a parser that understands the whole structure, including whitespace and comments, and provides an interface for modifying things in place without changing anything around it (XML DOM)
That last one probably exists for very specific formats for very specific languages, but it’s not common. It’s a little more cumbersome to use as a programmer–anyone who has worked with XML DOM will attest to that–but it’s a lot nicer for end users.
Have you heard about KDL?
I’ll give my usual contribution to RSS feed discourse, which is that, news flash! RSS feeds support video!
It drives me crazy when podcasters are like, “thanks for listening to our audio podcasts. We also have a video feed for our YouTube subscribers.” Just let me have the video in PocketCasts please!
I feel you but i dont think podcasters point to youtube for video feeds because of a supposed limitation of RSS. They do it because of the storage and bandwidth costs of hosting video.
I’d think they’d get it back by not having to share their ad rev with Google. There’s something to be said for the economies of scale Google benefits from but with cloud services that’s not as relevant as it was.
I just wrote a YouTube scraper and exported to RSS and into my podcast client. Using YouTube any other way is masochism in comparison.
(Holocene or) Human Era calendar
That would represent all human history as one.
That sounds interesting, would most likely not be very popular with lots of people and a pain in the butt to implement but interesting.
There’s a cool video from In a Nutshell about it some years ago.
And also, the Dekatrian calendar
Where we would have a less broken, more regular, year calendar that is almost align with the moon cycle.
Oh many years ago in school I created something like that for an arts/creative writing project once, a calendar with 12, 30 day month based on sailor moon. Having it based on a magical girl manga gave me the freedom to declare the rest of the days to “days of evil” Was a fun project because I created a whole religion around it. 😁
PGP or GPG, however you spell it. You can encrypt stuff, protect your email from prying eyes!
Also FOSS in general.
Huge fan of PHP…I mean PGP, oh god auto correct, you scary 😳
The tooling around it needs to be brought up to snuff. It seems like it hasn’t evolved much in the last 20+ years.
I had a small team make an attempt to use it at work. Our conclusion was that it was too clunky. Email plugins would fool you into thinking it was encrypted when it wasn’t. When it did encrypt, the result wasn’t consistently readable by plugins on the receiving end. The most consistent method was to write a plaintext doc, encrypt it, and attach the encrypted version to the email. Also, key servers are setup by amateurs who maintain them in their spare time, and aren’t very reliable.
One of the more useful things we could do is have developers sign their git commits. GitHub can verify the signature using a similar setup to SSH keys.
It’s also possible to use TLS in a web of trust way, but the tooling around it doesn’t make it easy.
XMPP, RSS, …
XMPP is not a good protocol though. There’s a reason nobody uses it anymore.
I think it’s going to be interesting when the EU tries to enforce interoperability between the major messaging platforms. What are they going to do? They have some ridiculous targets like interoperable end-to-end encrypted group video calls in 5 years!
I use xmpp. It happens to be a great fit for a private family messaging service. Good interoperability between modern clients. I get that “nobody uses it” is hyperbole, but the internet is a big place and there is room for services without mass market appeal to thrive.
There’s a reason nobody uses it anymore.
Yeah, Google and Faceebook EEE’d it.
XMPP is not a good protocol though.
Do elaborate.
XMPP is very old and was created when nobody knew about mobile phones. It worked more like true messaging app less than messages store ( unlike matrix ).
Requirement of permanent tcp ip connection doesn’t work well for mobile + pretty much useful feature in xmpp ( like message history ) is optional. If something doesn’t work in xmpp most people would blame xmpp / jabber rather than the lack of feature support in their server
XMPP is very old
Seriously? That’s your argument? So is the wheel.
Requirement of permanent tcp ip connection doesn’t work well for mobile
I was under the impression PubSub was created for that.
Still, it’s an open extensible protocol.
XMPP is very old
Seriously? That’s your argument? So is the wheel.
They elaborated how that relates; usage scenario changed with mobile phones. XMPP is a bad match.
XMPP is a bad match.
The X is for extensible, so are a whole bunch of other protocols and people haven’t stopped using them, they get improved upon (for the most part).
The mentioned permanent tcp ip connection (which you don’t neccessarily have on mobile) too?
Seriously, if you do take one verse from the whole response, you get straw men you fighting with.
I just told you that jabber / xmpp was created in the times almost nobody knew or believed mobile phones can be a thing. Thus it got created in that way: many similarities of xmpp and e-mail, irc or icq which didn’t stand the passage of time.
Of course, you’re right xmpp evolved to get PubSub extension as an “optional feature” but because of its availability (or rather lack) - most servers didn’t support it even the client did support, xmpp didn’t win the acceptance of the end-users. It got some attention in the business world (cisco jabber) but not in the retail.
Business cannot work forever without clients willing to pay or at least use, so it died off even in the business.
End of story, try not to fighting with the straw men you created.
Of course, you’re right xmpp evolved to get PubSub extension as an “optional feature” but because of its availability (or rather lack) - most servers didn’t support it even the client did support, xmpp didn’t win the acceptance of the end-users. It got some attention in the business world (cisco jabber) but not in the retail.
That XMPP’s extensibility is in itself a strength and a weakness is indeed a valid argument, as you’ve exemplified. I was expecting you’d criticize OMEMO though…
Business cannot work forever without clients willing to pay or at least use, so it died off even in the business.
No, it didn’t die off, it’s still used. IRC is still used as well, probably more or less at the same level. But if you define usage as “used in business” well then probably just a few cases, yes.
I hadn’t heard of Cisco Jabber but i’ve heard of Google and Facebook - both companies’ messengers were, initially, based on XMPP but they EEE’d it once they got enough users and walled their gardens, dealing a major blow to the protocol.
End of story, try not to fighting with the straw men you created.
Can i fight my inner daemons at least? Please?
It worked more like true messaging app less than messages store ( unlike matrix ).
Can you please elaborate this point? I don’t understand what you mean by “true messaging app” and why that would be a bad thing?
Requirement of permanent tcp ip connection
Are you sure this is the case? Maybe back in the day, but my understanding is this isn’t true anymore
useful feature in xmpp ( like message history ) is optional
Why is user choice a bad thing? There’s a wealth of clients that implement the features you want
If something doesn’t work in xmpp most people would blame xmpp
This may not be an important point, but from my experience, people always blame the client and not the underlying protocol. If I face an issue with my browser, I’d likely blame the browser before I blame http.
There’s a reason nobody uses it anymore.
I and many others use it! And Google, meta, etc. Have used it but decided to lock it down.
Yes you’re right, there’s a reason people don’t use it as much, which is because these corporations embraced it, dominated it, then extinguished it.
But XMPP is honestly my favorite comm protocol and the most impressive imo.
For RSS I honestly don’t see a point, at least for me. What’s the use for having update feeds in a unified format when I still have to go to each fucking site to view the full text? I completely see the point of RSS when all I need is in the feed. But I hate going from different UI to different UI to get the full content. I want something like inoreader.com for self-hosting.
What’s the use for having update feeds in a unified format when I still have to go to each fucking site to view the full text
This has nothing to do with RSS, it is the author’s choice. It’s like someone who posts links to their articles on Twitter / Facebook / Reddit, same thing. The platform doesn’t prevent you from putting the entire content there, and in fact, many do, especially with RSS.
One benefit of RSS though is that because it is an open protocol, the problem you mention already has solutions, which auto fetch the articles for you. That wouldn’t be possible without an open protocol like RSS
Moreover, I’d argue even with that, RSS is still a huge plus. To have all your content’s headlines in one UI, and potentially you can filter or sort them however you want, that’s pretty awesome.
RSS works great for me though.
I have an app on my not-so-smart phone to read news when commuting. It is not a long journey so I just want to have a quick glance at the headlines and read the actual articles that I want to. There are only 6 sites that I am interested, but still will take quite some work to crawl from the proper websites. RSS in turn is unified so I don’t need to worry about their website layouts, formats, etc. It also gives me an URL to the actual content which I can use readability/reader mode library to parse and further reduce unnecessary contents.
Quite the opposite, I hope more informational sites offer/keep RSS! (Some removed RSS typically after a revamp, design change)
Mastodon offers rss for both keywords and users
Miniflux is likely to tick most of your boxes. It’s self hostable and can download the full article without extra clicks / having to visit the source.
Thanks, I’ll take a look. These days Inoreader also shows only the summary, making it useless for me.
The content of the feed depends on the content creator, not on RSS.
I know that. But RSS is like 95% used for news feeds and that’s what I’m talking about. The way RSS is overwhelmingly used is making the whole thing useless (to me).
well, then just consider those giving shitty support for it as if they wouldn’t be supporting it at all
