IceCubesApp
IceCubesApp copied to clipboard
Dimillian
Some instances are not supported
App version 0.7 (711) iOS 16.2 / iPhone 12 Pro
I can't add the account for my instance. I enter the domain "mastodon.denibol.com" but it does nothing. It's a Pleroma backend but other Mastodon clients does not have any problem loggin in. Instance metadata on https://mastodon.denibol.com/api/v1/instance 
Seems like Plemora don't have configuration in the root response for this API.
public struct Configuration: Codable {
public struct Statuses: Codable {
public let maxCharacters: Int
public let maxMediaAttachments: Int
}
public struct Polls: Codable {
public let maxOptions: Int
public let maxCharactersPerOption: Int
public let minExpiration: Int
public let maxExpiration: Int
}
public let statuses: Statuses
public let polls: Polls
}
I didn't look at the differences between Mastodon and Plemora yet, will probably add support for it down the line if i's close enough, but the difference on this API tell me it's not close enough.
The differences between the Mastodon API and the Pleroma compatible backend are documented here: https://docs-develop.pleroma.social/backend/development/API/differences_in_mastoapi_responses/
Hi @Dimillian
Similar problem but not the same: it says the instance is not supported…
Is there any blocking limitation on this instance?
Instance: mastodon.partecipa.digital App version: 1.0 (841) iOS 16.2 (iPhone 8)
It would also be great if e.g. pixelfed.de or pixelfed.social would be supported.
Can you sign in? It's actually supposed to work as it's Mastodon API. I'll look why the timeline is not parsed.
Hello, I believe the problem is that the Instance.swift model has some items that are not present in Pleroma, or other servers that implement the Mastodon API.
I found this issue since I'm also having some trouble connecting Ice Cubes to a GoToSocial instance. GTS provides a Mastodon-compatible API, but with some missing parts. Most apps still work, though.
I did some debugging from the instance side, and I see that the app makes a request to the /api/v1/instance endpoint. Comparing the /api/v1/instance response from a GTS instance with the response from the mastodon.social instance, the missing items from the GTS response seem to be "rules" and "languages". I also tested looking at the API response from mastodon.partecipa.digital and mastodon.denibol.com, and both are also missing the "rules" array that's present in the model.
I'm not sure if there are more differences that could cause the "not supported" message to appear, since I'm not a Swift programmer and I didn't take too deep of a dive into the codebase. However, if Swift allows making items in the model optional, that could allow users to log in to those instances.
Thank you for making this app, and thanks for considering support for other server software!
It's perfectly fine if we make this array optional, it should be actually, I'll do that soon. Thanks for the investigation!
I probably should have mentioned my GTS instance earlier, but could you test social.quake.host as well? It's missing both the rules and languages array.
All good there too!
This new version will be available in a few hours, so everyone will be able to test
Well, with Pleroma backend now it shows the instance info and the sign in button but it does nothing else. It seems to think for a second but nothing happen.
Why does Plemora want so much to do things differently? I'll take another look tomorrow and I guess I need to create a Plemora account somewhere.
Well, with Pleroma backend now it shows the instance info and the sign in button but it does nothing else. It seems to think for a second but nothing happen.
Just for information, it does the same on my GoToSocial instance.
Why does Plemora want so much to do things differently? I'll take another look tomorrow and I guess I need to create a Plemora account somewhere.
if you want i can give you an account on post.ebin.club, i'm one of the Pleroma frontend developers. Our MastodonAPI has been implemented long long time ago and probably not on par with modern mastodon implementations.
Originally we used QvitterAPI but after some time switched to MastodonAPI + our own extensions due to... circumstances.
I downloaded Xcode and poked around the app a little, and discovered that changing vapidKey to an optional value in the InstanceApp.swift model is enough to be able to log in to a GoToSocial instance. However, it leads to a Hotel California situation where I can't logout because the Settings tab calls the /api/v1/preferences endpoint, which isn't implemented yet. Still, this is better than not being able to login at all, and I'd be happy with that.
Regarding Pleroma, the server is complaining that client_name and redirect_uris are missing from the /api/v1/apps call. They are there in a /api/v1/apps?client_name=[...]&redirect_uris=[...] format, which I don't know if Pleroma accepts.
Maybe they accept only form data? Or maybe JSON? JSON POST would be good as I already do it for stuff like status post / edit.
Should accept both form data and JSON i think, but historically PleromaFE been using form data. IIRC traditionally POST requests are using parameters in the body (i.e. form data) not in the url (like GET).
You might need to also specify scopes, too. This is one of the most pain points to us because scopes tend to change from time to time as new features are added.
here's a snippet of relevant code from PleromaFE:
const url = `${instance}/api/v1/apps`
const form = new window.FormData()
form.append('client_name', `PleromaFE_${window.___pleromafe_commit_hash}_${(new Date()).toISOString()}`)
form.append('redirect_uris', REDIRECT_URI)
form.append('scopes', 'read write follow push admin')
return window.fetch(url, {
method: 'POST',
body: form
})
hope it helps
Yeah right now my client is doing URL encoded form, not as body. But i'll try to turn them to JSON to see what happens.
Yeah, Pleroma/Akkoma require POST data in the body, not the URL (which is fair since that's what the HTML spec strongly recommends.) Just fixed this for madon which made the same assumption.
i can open the sign in dialog for a pixelfed instance but as soon as I authorised access the dialog closes and I am back at the sign in without the account added.
Just an update. tested the latest release on GoToSocial instance. its working now.
Following from @anantshri: Trying to log into my akkoma instance just spins now without moving forward.
Just an update. tested the latest release on GoToSocial instance. its working now.
It didn't work for me - using GTS 0.6.0 git-f9e5ec9.
The API call to api/v1/accounts/verify_credentials was failing as the 'sensitive' field was missing from the response.
However GTS have fixed this at their end (superseriousbusiness/gotosocial/issues/1332) and after building from their git repo, I can log in and see my timeline.
Nice, feel like it'll be less work for me if backend actually start to be closer to Mastodon haha
Link to pleroma open issue about this topic here: https://git.pleroma.social/pleroma/pleroma/-/issues/3057
Am seeing the same issue as @perigrin on https://fediverse.catgirlin.space
I just migrated to https://genserver.social and it doesn't work there either. Another Pleroma site. I'm hoping that things can be worked out here as IceCubes is by far my FAVORITE fediverse app. 😎
I hope as well that IceCubes will Support Pleroma.
The moment I hit "Anmelden" nothing happens
Same issue with this instance (fgc.network). Click sign in, spins for a second, nothing, then stops.
