@[email protected] @[email protected] -- Now I see why I missed it. These additional properties aren't actually defined in the AS spec but only the FEP(?) immediately after implying that the pagination properties were all specified in the AS spec. I get it now, but maybe a wee bit of word-smithing in the FEP could make this a bit clearer.

I guess the question remains how to determine if a site offers cursor-based pagination or recognises 'maxItems' per FEP-9f9f. Guess you need to just try it, maybe with an odd number like 19, and see if what you get back is "consistent" with your request, to see if you should continue trying to use client defined pagination for this site. (This might be another good use case for the server 'capability' mechanism.)

@[email protected] -- Thanks. Don't know how I missed that, but I'll start using it right away. Cheers.

@[email protected] As an opinion that is likely to be very unpopular... the page size ideally should be set by the client. Only they know their resource makeup and ability to process the returned information.

Otherwise, we tend to run page size between 60 and 100 depending on the content. And if it's less than 100 entries (and especially when returning an id-list rather than a list of activities), we'll usually just send them out without paging.

The desire is to balance resource usage to get the highest rate of information transfer, and those are the only levers we have available, and they (currently) aren't settable by clients, so it seems the best we can do is default to "large chunks".

I admit that I'm not fond of the page size of 12 that I found in Eugen's followers list of over half a million entries (some years ago). That's a lot of network requests and makes their clients work a lot harder than they need to.

@[email protected] -- It's also used for the username component of email addresses iirc; as these are originally also specified as 7-bit US-ASCII. So I convert local usernames with idn. Just something I did out of habit really. You can use UTF-8 if you want, so I'm only saying that punycode seems to federate better based on my experience. We tested this with a bunch of fediverse software at the time and it just worked. We'll accept either.

@[email protected] -- I've just tested and that account also works fine with Hubzilla. I will mention that your implementation in this case uses url-encoded usernames while ours uses punycode. They should be able to interact just fine, but the fact that there are multiple ways to arrive at a solution could cause a bit of confusion for implementers.

You'll need to use punycode if you wish to federate with the diaspora protocol or email or any other projects or protocols which restrict the character set for usernames. So it might end up being a more flexible solution in the long run and should work fine with every other fediverse project today. ASCII-restricted software will just use the xn-- name; and all their links and buttons should work fine.

Url-encoding should also work, but perhaps not so universally and easily as punycode; as witnessed by the number of issues documented in this thread.

@[email protected] -- Just looked again... this was first introduced as a hidden feature in redmatrix around 2013-2014, and so may also be available currently in Hubzilla (behind the "system.unicode_usernames" feature toggle). There were some major changes in 2019 that to my knowledge weren't ever backported. I think these only applied to local usernames and not remote usernames, but the functionality in hubzilla still might need to be verified.