Post 3438862 by kaniini@pleroma.site
(DIR) More posts by kaniini@pleroma.site
(DIR) Post #3434955 by Gargron@mastodon.social
2019-01-27T17:32:59Z
0 likes, 2 repeats
Summary of the #Pleroma API changes:Pleroma emulates the Mastodon REST API to piggyback on the Mastodon apps that already exist (fair enough). Pleroma changes IDs returned by their emulated API, from numbers encoded as base 10 strings, to numbers encoded as base 62 strings (difference being the method by which they can be sorted in typed systems) (1/2)
(DIR) Post #3434959 by Gargron@mastodon.social
2019-01-27T17:35:17Z
1 likes, 1 repeats
Pleroma users send complaints verging on extremely rude to Mastodon app devs, justify it with the fact that Mastodon documentation only specifies IDs being encoded as strings in JSON, not that they are in base 10 or 64 bit. I posit that the Mastodon API documentation is descriptive rather then prescriptive, and the API was never intended to be implemented by non-Mastodon software, and therefore prior assumptions of app devs based on Mastodon API's observable behaviour were not wrong. (2/2)
(DIR) Post #3434964 by Gargron@mastodon.social
2019-01-27T17:37:57Z
0 likes, 1 repeats
I do not have any judgement to offer here, except that app devs are definitely not to blame here, and my intent with this summary is to clarify the situation.
(DIR) Post #3434995 by maryjane@social.coletivos.org
2019-01-27T17:40:19Z
0 likes, 0 repeats
@GargronOne day someone should go around and ask the developers of the different client apps, if they view their apps as a integral and exclusive part of mastodon, or if they see it as activitypub apps and welcome the fact that several federated services use them.Some just work with pleromabwithout the devs putting work into it, others work to improve support pleroma and even work to support pixelfed and peertube.1/2
(DIR) Post #3435069 by DetectiveHyde@shigusegubu.club
2019-01-27T17:43:07.672864Z
2 likes, 1 repeats
@Gargron I posit that you're a fucking fluoridated indian call center GOON
(DIR) Post #3435138 by WAHa_06x36@mastodon.social
2019-01-27T17:45:47Z
0 likes, 0 repeats
@maryjane @Gargron No Mastodon apps are ActivityPub apps, as they use the internal Mastodon client API, and no ActivityPub protocols.
(DIR) Post #3435186 by Echolocation@kawen.space
2019-01-27T17:47:28.569205Z
1 likes, 0 repeats
@DetectiveHyde @Gargron i posit a block in 3...2...1
(DIR) Post #3435215 by maryjane@social.coletivos.org
2019-01-27T17:48:53Z
0 likes, 0 repeats
@Gargron2/2 The expression "piggyback mastodon apps" implies:1 - pleroma devs are a bit leechers2 - client apps are mastodonSo "fair enough", but not compleatly cool. Who cares if they copy the API, it's free software right?
(DIR) Post #3435268 by WAHa_06x36@mastodon.social
2019-01-27T17:50:47Z
0 likes, 0 repeats
@maryjane @Gargron The thing is, it is an internal API with no spec. It is indeed fair enough to copy it, but it is up to whoever does to maintain compatibility, and doing so is not that easy. Pleroma decided to just not bother, and the fallout of that all lands on the heads of the app makers, and that is not really cool either.
(DIR) Post #3435443 by WAHa_06x36@mastodon.social
2019-01-27T17:47:07Z
0 likes, 0 repeats
@maryjane @Gargron Pleroma attempts to implement this same internal API, but has now broken it (and do break it in other subtle ways too). As far as I know, PixelFed and PeerTube have their own, completely different client APIs, and any app that supports them just implements all the different APIs.
(DIR) Post #3435444 by maryjane@social.coletivos.org
2019-01-27T17:56:20Z
0 likes, 0 repeats
@WAHa_06x36Ok replace #ActivityPub with #Fediverse in my last post, it makes it more clear.Second isnt the API Free Software? (even if created by mastodon devs)Third, thanks for pointing out that pixelfed and peertube have different API's (big shock), just reinforces my argument that some Fediverse client apps have a broader scope and do an effort to support more than just microblogging, and maybe they dont see themselfs as just a mastodon thingy.@Gargron
(DIR) Post #3435511 by WAHa_06x36@mastodon.social
2019-01-27T17:59:08Z
0 likes, 0 repeats
@maryjane @Gargron The Mastodon client API is not a Fediverse API either. It’s an internal API for Mastodon. And I’m not sure what point you’re trying to make with the rest?
(DIR) Post #3435637 by DJ_Pure_Applesauce@mastodon.social
2019-01-27T18:02:21Z
0 likes, 0 repeats
@Gargron "the API was never intended to be implemented by non-Mastodon software"that says it all; no blame/anger is justified.
(DIR) Post #3435638 by 361.xj9@social.sunshinegardens.org
2019-01-27T18:03:35.636965Z
0 likes, 0 repeats
@DJ_Pure_Applesauce @Gargron lmao too late gargoyle 😂😂
(DIR) Post #3435819 by maryjane@social.coletivos.org
2019-01-27T18:11:23Z
0 likes, 0 repeats
@WAHa_06x36My point, in my first post is seeing client apps being considered as mastodon apps, and would be nice to hear from the devs if they consider their apps as such.@Gargron
(DIR) Post #3435897 by maryjane@social.coletivos.org
2019-01-27T18:14:13Z
0 likes, 0 repeats
@WAHa_06x36And i did not say the mastodon API was a Fediverse API. I said it's Free Software, so there shouldn't be an issue with being used by others.@Gargron
(DIR) Post #3435923 by WAHa_06x36@mastodon.social
2019-01-27T18:14:53Z
0 likes, 0 repeats
@maryjane @Gargron I make one, and yes, I do, since I use the internal Mastodon client API. I’d love it if it worked with other server software, but I consider that to be the responsibility of the authors of that software, since they are cloning a private API.
(DIR) Post #3435932 by WAHa_06x36@mastodon.social
2019-01-27T18:15:22Z
0 likes, 0 repeats
@maryjane @Gargron Nobody has said there is. The original post said as much.
(DIR) Post #3436115 by maryjane@social.coletivos.org
2019-01-27T18:22:36Z
0 likes, 0 repeats
@WAHa_06x36Ok good to ear your oppinion on the matter. Which one by the way?@Gargron
(DIR) Post #3436125 by WAHa_06x36@mastodon.social
2019-01-27T18:22:54Z
0 likes, 0 repeats
@maryjane It's @tootapp.
(DIR) Post #3436568 by maryjane@social.coletivos.org
2019-01-27T18:33:59Z
0 likes, 0 repeats
@WAHa_06x36The original post uses the expression "piggyback" and "fair enough". It's okish...@Gargron
(DIR) Post #3436650 by maryjane@social.coletivos.org
2019-01-27T18:36:12Z
0 likes, 0 repeats
@WAHa_06x36See you also developed Kereha. That is used by #piratebox correct?
(DIR) Post #3436710 by WAHa_06x36@mastodon.social
2019-01-27T18:38:25Z
0 likes, 0 repeats
@maryjane @Gargron Yes, because it has obvious problems, as it wasn't designed for that and if you do, it will probably lead to problems down the road. As it did.But you are perfectly ALLOWED to do it. That does not mean it's always a great idea.
(DIR) Post #3436746 by WAHa_06x36@mastodon.social
2019-01-27T18:39:24Z
0 likes, 0 repeats
@maryjane Possibly! I have no idea about it, I made that something like fifteen years ago!
(DIR) Post #3438862 by kaniini@pleroma.site
2019-01-27T19:40:38.265667Z
3 likes, 3 repeats
@Gargronthere have not been any complaints sent to Mastodon app devs, rude or otherwise.we have a growing set of relationships with app developers who are committed to supporting both Mastodon and the Pleroma API extensions. if we were hostile to devs, that would not be happening.it is our policy to only discuss with app devs who have expressed direct interest in supporting Pleroma. that includes some apps that support Mastodon, others that support GNU Social and others that support Misskey as well as Pleroma.I find your claims that we have been rude and demanding with app devs who have expressed no interest in supporting our project to be disappointing, and as explained above patently false. please correct your statement.
(DIR) Post #3439550 by WAHa_06x36@mastodon.social
2019-01-27T19:48:52Z
0 likes, 0 repeats
@kaniini @Gargron He said Pleroma users, and let me tell you, you definitely have some seriously rude users and they have been sending their rubbish my way.
(DIR) Post #3439551 by kaniini@pleroma.site
2019-01-27T20:03:16.144491Z
3 likes, 0 repeats
@WAHa_06x36I'm disappointed to hear that you have gotten some hate mail, but as we have explained to the Pleroma community, we only support clients which are certified to work with Pleroma.those are the ones in the readme file, and Toot! has never been on the list, so it's really their fault for depending on a client we never certified to begin with.it is unfortunate that Pleroma uses 128-bit IDs, and it is unfortunate that you have no interest in partnering with us.we solicited input on the FlakeIDs scheme several months before implementing it. had you been working with us, you would have been aware of it and could have requested we stick with a 64-bit ID.unfortunately, now, it is too late. the FlakeIDs change works fine with the clients we officially support and certify as Pleroma-compatible.indeed, it is also unfortunate that users bought Toot!.app without reading our certified app list, but obviously that is something out of my control.at any rate, if you would like to release your app under free license terms and support FlakeIDs, it is always possible to work together in the future. considering a user added features to Pleroma explicitly to support Toot! despite knowing it is a non-certified app, I would say there is interest, and in interest there are business opportunities.something to think about anyway. more customers are always better than less, no?
(DIR) Post #3439641 by doublah@mstdn.io
2019-01-27T19:47:21Z
0 likes, 0 repeats
@Gargron bit dishonest as only one app was effected afaik and most app devs are on good terms without pleroma devs with no "rudeness" at all
(DIR) Post #3439642 by WAHa_06x36@mastodon.social
2019-01-27T19:50:16Z
0 likes, 0 repeats
@doublah At least two apps, and there has been plenty of rudeness going about.
(DIR) Post #3439643 by kaniini@pleroma.site
2019-01-27T20:06:07.440880Z
3 likes, 0 repeats
@WAHa_06x36no, it's really just you. Subway Tooter was effected but the author works with us and fixed his implementation quickly. Subway Tooter failing testing in fact delayed deployment of the change by a week.we did not deploy the change until all clients on the list of officially supported clients were green.@doublah
(DIR) Post #3439659 by a_breakin_glass@cybre.space
2019-01-27T19:10:48Z
1 likes, 0 repeats
@gargron "app devs are definitely not to blame here"making assumptions about an API is totally not the assumer's fault, not at all
(DIR) Post #3439674 by chara@toot.cat
2019-01-27T19:23:42Z
1 likes, 1 repeats
@Gargron "and the API was never intended to be implemented by non-Mastodon software" wow, so other me was right, and you really are just repeating Twitter. they hate other people using their API too *grins*glad to see confirmation of our fears. well, not really GLAD, but...eh, we kinda expected this from you, Gargron.
(DIR) Post #3440048 by charlag@birb.site
2019-01-27T20:13:15Z
0 likes, 0 repeats
@kaniini @WAHa_06x36 hey, I'm not sure why you replied that, there were really some random rude people coming out of nowhere. Not saying it's your fault or anything but I've personally banned some people.GPL is incompatible with App Store, unfortunately (see VLC case e.g.) but permissive licenses are.
(DIR) Post #3440049 by kaniini@pleroma.site
2019-01-27T20:19:58.107641Z
0 likes, 0 repeats
@charlagunfortunately auditable source code is basically a hard requirement for any client to be certified as Pleroma-compatible.clients that have such certification are recommendations from the project and are based in part on an assessment of the codebase: we want to be certain we are recommending a client which follows the same security and privacy practices we do.and as I said publicly a moment ago, spending $4 on an app not certified to work with Pleroma and then getting pissed when it breaks, well that's the buyer's fault honestly.I'm sorry that he got hate mail, but avoiding situations like this is explicitly why we have the policies we do for recommending Pleroma clients.@WAHa_06x36
(DIR) Post #3441542 by chara@toot.cat
2019-01-27T21:17:59Z
0 likes, 0 repeats
@dgold @Gargron I think it's high time to give him what he wants then. if he can't handle the pressure of living with a community or responding to anyone's needs outside his GitHub pals then let's just let him have his mini-Twitter. the rest of us don't need to federate with it
(DIR) Post #3447100 by Gargron@mastodon.social
2019-01-28T00:03:29Z
2 likes, 2 repeats
It is regrettable that I was only notified about this after the ID change already took place, because we could have clarified things and involved the Mastodon app devs, and have some say in the matter.Now clarifying an already existing API of ours would be exclusionary towards Pleroma. If you heard about our documentation changing to specify IDs as 64 bit numbers yesterday, it has been changed again today afternoon to keep Pleroma compatible.
(DIR) Post #3451923 by gaditb@icosahedron.website
2019-01-27T17:45:59Z
1 likes, 2 repeats
@Gargron
(DIR) Post #3452418 by heluecht@pirati.ca
2019-01-27T20:28:51Z
1 likes, 1 repeats
@Gargron I'm slightly irritated by "the API was never intended to be implemented by non-Mastodon software". I'm a strong believer of the open source principles that developers of different systems should support each other.I think it would be best if API users (app developers) and API provider (server systems) could coordinate each other, since we all do share only a small part of the whole cake and we shouldn't fight against each other. Instead we should combine our forces to improve the whole fediverse.
(DIR) Post #3458803 by WAHa_06x36@mastodon.social
2019-01-27T21:28:47Z
0 likes, 0 repeats
@kaniini @charlag Incidentally, though, if you wanted source code access to verify it I'm happy to give it to you, but that would obviously be if I can get it it working with Pleroma again.
(DIR) Post #3458804 by kaniini@pleroma.site
2019-01-28T07:48:52.310738Z
0 likes, 0 repeats
@WAHa_06x36 @charlag I would be open to looking at the code and adapting it to efficiently handle IDs of any sort. I've been doing systems-level programming for the majority of my life so I believe I can come up with something that will suit your needs that will meet or exceed your current hashtable performance, while also working well for us.i do not have an iOS device though, so I won't be able to test effectively.
(DIR) Post #3458816 by tateisu@mastodon.juggler.jp
2019-01-28T07:43:33Z
0 likes, 0 repeats
@kaniini @WAHa_06x36 @doublah what about you said? ST still use long id in mastdon-like servers.
(DIR) Post #3458817 by kaniini@pleroma.site
2019-01-28T07:49:35.092370Z
0 likes, 0 repeats
@tateisu @doublah @WAHa_06x36 well Pleroma is mastodon-style but uses IDs like Misskey. I guess it wouldn't be that hard for you to adjust ST for that quirk.
(DIR) Post #3458962 by WAHa_06x36@mastodon.social
2019-01-28T07:53:24Z
0 likes, 0 repeats
@kaniini @charlag If you have a Bitbucket account, I can add you to the project.
(DIR) Post #3458963 by kaniini@pleroma.site
2019-01-28T07:55:14.643027Z
0 likes, 0 repeats
@WAHa_06x36 @charlag I do, I will have to reset the password because I haven't used it in years. will circle back.
(DIR) Post #3524128 by WAHa_06x36@mastodon.social
2019-01-29T21:17:53Z
0 likes, 0 repeats
@kaniini How are you planning to handle web push notifications in Pleroma? Notification payloads have a number-typed notfication id field.
(DIR) Post #3524129 by kaniini@pleroma.site
2019-01-29T21:21:11.946832Z
0 likes, 0 repeats
@WAHa_06x36 Pleroma already supports web push notifications. Notification objects indeed have a numeric ID (notification_id) and that is presented accordingly.
(DIR) Post #3524172 by WAHa_06x36@mastodon.social
2019-01-29T21:21:42Z
0 likes, 0 repeats
@kaniini So notifications do not use the new-style ids?
(DIR) Post #3524173 by kaniini@pleroma.site
2019-01-29T21:22:09.888233Z
0 likes, 0 repeats
@WAHa_06x36 correct.
(DIR) Post #3524221 by WAHa_06x36@mastodon.social
2019-01-29T21:22:37Z
0 likes, 0 repeats
@kaniini All right. Looking into what is needed to use string IDs now.
(DIR) Post #3524222 by kaniini@pleroma.site
2019-01-29T21:24:05.820837Z
0 likes, 0 repeats
@WAHa_06x36 i suggest using a TST structure instead of a hashtable, it will be more memory compact (unless the hash function is very well balanced across bucketspace) and lookups will be more efficient (no need to hash the data, just walk the bytes in sequence).
(DIR) Post #3524239 by kaniini@pleroma.site
2019-01-29T21:24:34.965421Z
0 likes, 0 repeats
@WAHa_06x36 (if you need help designing and implementing a TST, the door is open, I have just been very busy.)
(DIR) Post #3524429 by WAHa_06x36@mastodon.social
2019-01-29T21:26:18Z
0 likes, 0 repeats
@kaniini Robin Hood hashing lets you get very compact hash tables, so it is already about as compact as it can get, and really fast. Also, touching that is a bit too likely to introduce problems so I will just use hashes of strings there when needed. The main thing to fix is the timeline cache format, which has so far just been a long array of ints.
(DIR) Post #3524430 by WAHa_06x36@mastodon.social
2019-01-29T21:29:06Z
0 likes, 0 repeats
@kaniini The current cache format is basically a fixed-size hash table at the start of a file, followed by actual entry data. The hash table contains (key, offset, timestamp) tuples. This works great for a cache, as you can just mmap() the start of the file for really fast lookups of where the actual data is. Occasionally, the oldest entries will be discarded and the trailing data compacted.
(DIR) Post #3524431 by kaniini@pleroma.site
2019-01-29T21:31:00.447453Z
0 likes, 0 repeats
@WAHa_06x36 yeah, makes sense. also makes sense why you got hit so hard by the IDs issue.
(DIR) Post #3524432 by WAHa_06x36@mastodon.social
2019-01-27T19:42:32Z
0 likes, 0 repeats
@a_breakin_glass I made assumptions, which I checked with Eugen and the Mastodon devs, and they confirmed they were good and intended assumptions.
(DIR) Post #3524433 by a_breakin_glass@cybre.space
2019-01-27T20:09:06Z
0 likes, 0 repeats
@WAHa_06x36 but it still isn't a reliable assumption
(DIR) Post #3524434 by WAHa_06x36@mastodon.social
2019-01-27T21:23:57Z
0 likes, 0 repeats
@a_breakin_glass But it is. It is now also documented.
(DIR) Post #3524435 by a_breakin_glass@cybre.space
2019-01-27T21:24:16Z
0 likes, 0 repeats
@WAHa_06x36 not currently
(DIR) Post #3524436 by WAHa_06x36@mastodon.social
2019-01-27T21:24:58Z
0 likes, 0 repeats
@a_breakin_glass https://docs.joinmastodon.org/api/entities/"All IDs are encoded as string representations of integers."
(DIR) Post #3524437 by a_breakin_glass@cybre.space
2019-01-27T21:27:41Z
1 likes, 0 repeats
@WAHa_06x36 it doesn't specify the base and so on, though
(DIR) Post #3524463 by WAHa_06x36@mastodon.social
2019-01-27T21:29:55Z
0 likes, 0 repeats
@a_breakin_glass That's just being intentionally obtuse.
(DIR) Post #3524464 by a_breakin_glass@cybre.space
2019-01-27T21:32:42Z
1 likes, 0 repeats
@WAHa_06x36 how? the type of integer encoded by the string isn't specified
(DIR) Post #9kQU0ycXnJpKfrZBY0 by Gargron@mastodon.social
2019-01-28T00:23:08Z
0 likes, 0 repeats
@Xyc0 Not sure what you mean to be honest! Do you pull the docs from master?
(DIR) Post #9kQU23NdaGiHj26j7A by brunoph@mastodon.technology
2019-01-28T00:21:43Z
0 likes, 0 repeats
@Gargron 🤦♂️
(DIR) Post #9kQU2Fsv5mrmVWpsXY by anthracite@dragon.style
2019-01-28T02:31:20Z
0 likes, 0 repeats
@Gargron oh geez this sounds like a giant mess.
(DIR) Post #9kQU3lHbq8sIB26PR2 by jeffmc@pdx.social
2019-01-27T17:58:49Z
0 likes, 0 repeats
@Gargron I would never assume an ID string in JSON would ever be a 64 bit number. Twitter went string in their ID (unfortunately they had to have id_string, because they were dumb when they first came out and used a 32 bit number on the key "id"). Also, due to JSON's idiocy on number overflow, a string is best. If someone made an assumption on their client, that is their issue, not Mastodon's, IMHO.
(DIR) Post #9kQU7MyY9kj3wmuLpI by Gargron@mastodon.social
2019-01-27T20:33:33Z
0 likes, 0 repeats
@heluecht I think maybe you misunderstand. The Mastodon REST API (client-to-server) was designed specifically for Mastodon, in stark comparison to ActivityPub, which was designed by a working group as a standard through a bureaucratic process at the W3C. Pleroma or Misskey emulating it was not an intended use case that was planned for. It's an "on your own risk" thing that they do.
(DIR) Post #9kQU81DUXcRekiCqfY by cj@mastodon.technology
2019-01-27T23:55:25Z
1 likes, 1 repeats
@Gargron @heluecht Will Mastodon will consider implementing the C2S #ActivityPub protocol, and not just the S2S part?
(DIR) Post #9kQU8CfXxeQGGuPuQS by K0nrad@mastodon.social
2019-01-28T08:09:11Z
0 likes, 0 repeats
@Gargron That's why documentation and specification are seperate documents …