Need community help to release 1.0.0 version

[dilame]

I just released pre-major version with re-invented framework. https://github.com/dilame/instagram-private-api/tree/v1.0.0

This is pre-major release without any useful functionality. I decided to start writing v1 from scratch because old code turned into uncontrollable set of related classes that inconvenient to use for both maintainers and users. I developed new simple structure that, i hope, you will like. Now it works like this

import { IgApiClient } from './src';
const ig = new IgApiClient();
ig.state.generateDevice(process.env.IG_USERNAME);
const response = await ig.auth.login(process.env.IG_USERNAME, process.env.IG_PASSWORD);
const feed = await ig.feed.accountFollowersFeed(response.pk).get();

What do you think about such new stateful approach?

Now i need a little help with finalize v1. If you are using this library, please take some time to write at least one file.

[zzarcon]

Thanks for the proposal @dilame !

I have some questions:

ig.state.generateDevice(process.env.IG_USERNAME);

What is that mean to do? It is not clear to me, and since is not returning anything, I assume it has some side effects on the state class? I will prefer instead something like:

const device = new Device(...);

ig.setDevice(device)

// or

const ig = new IgApiClient({device})

Also, I think it will be helpful if you write down the interfaces, like for response, feed, etc. That way it will be easier to understand how the entities work together :)

Finally, is the return of ig.auth.login something that we need to pass around all the time (like we do now with session)?

Thanks for the proposal, I think it's a great initiative!

[dilame]

Thanks for response, @zzarcon I want to get rid of unnecessary entities. In current implementation we have too much stateful entities, and it's still not enough for convenient state management that we need. The main concept of new API client is god object (not in the anti-pattern sense) with shared state. It's not always clear where to store the data like signature key per session (sometimes you want to use different keys for different accounts), checkpoint result, challenge state, cookies. Plus many people wants to store all this data in an persistant storage like redis, postgres, files, any other. This is why i decided to throw away different stateful classes like device and session. Instead i suggest to use one Store class for all the data. It's simple to serialize it and save in the persistant storage, and then fetch state from storage and deserialize it back to get exact client copy. I want users to have an ability to implement their own storage class with their business logic. Plus i personally don't like to pass session object every time i want to make a request. In my opinion, this makes the code dirtier for both users and library maintainers.

What is that mean to do? It is not clear to me, and since is not returning anything, I assume it has some side effects on the state class?

Yes, it has side effects since we have state.

https://github.com/dilame/instagram-private-api/blob/v1.0.0-0/src/core/state.ts#L62

Also, I think it will be helpful if you write down the interfaces, like for response, feed, etc. That way it will be easier to understand how the entities work together :)

I already did 😄 You can see it here https://github.com/dilame/instagram-private-api/tree/v1.0.0-0/src/feeds Is that what you had in mind? Or something other?

Finally, is the return of ig.auth.login something that we need to pass around all the time (like we do now with session)?

No. We pass pk here just to get feed of logged in user, because instagram doesn't has endpoint to get like /api/v1/followers/self, so we need to pass the account id even if we need our own followers.

Basically i think i already described main part of interfaces in new branch https://github.com/dilame/instagram-private-api/tree/v1.0.0-0 You can explore it, there is not too much code, i removed old code here. This version already works, you can execute the usage example from my first post in this issue.

If you have any questions, I'd love to hear them.

[dilame]

Not a very important addition I'm not sure of. I want to generate response interface for every endpoint for users to have almost exact typings in In each individual case. For example - we have profile response from endpoint /api/v1/users/:id/info that looks like this (just a random account) https://gist.github.com/dilame/7eddd2ac35a2aed7af8be537500263af You copy this JSON, paste it here https://transform.now.sh/json-to-ts-interface/ and get generated intefrace

Create file profile.response.ts (or something like) that exports generated interface, and this interface will be used only for one endpoint. For other endpoints this work should be repeated.

So, i'm not sure if we need such detalization. On the one hand it is convenient for the user, on the other hand it is more work for maintainers.

Need advice. What do you think about it?

[thefilmmaking]

Plus i personally don't like to pass session object every time i want to make a request. In my opinion, this makes the code dirtier for both users and library maintainers.

This has definitely been the case with my code and you're absolutely right. I'm really liking where you're taking things.

Plus many people wants to store all this data in an persistent storage like redis, postgres, files, any other.

Absolutely. I've had a lot of issues when trying to manage storage data. I've been trying to keep session data in mongo, but it's been a bit messy, so I think you're proposal would be great.

Also, would be happy to contribute but not sure where I could help (not proficient in TS).

[dilame]

Thanks for response, @thefilmmaking ! If you really want to contribute, you can start with simple existing module like https://github.com/dilame/instagram-private-api/blob/master/src/v1/like.ts or https://github.com/dilame/instagram-private-api/blob/master/src/v1/relationship.ts or any other that you like For example, if you want to take like.js than you have to create repositories/like.repository.ts and implement methods from source following the example auth.repository.ts https://github.com/dilame/instagram-private-api/blob/v1.0.0-0/src/repositories/auth.repository.ts You don't have to be proficient in TS since TS is superset of JS, so you could just write JS code, i will add typings later. But, for real, TS is not so hard, you just write JS and add types. If you are familiar with JS you will learn TS basics in couple of minutes just by looking at the examples.

I don't have enough time to explain it in more detail right now, but i'll try to do it tomorrow if it's not clear enough.

[thefilmmaking]

I'll look into TS. As an example, in the case of the auth.repository.ts, which methods from source did you implement? I can't find the original that you adapted from/changed (unless I'm misunderstanding what you meant).

[heychazza]

Will you be fixing the registering issue? I can't seem to register via email with your api.

[dilame]

I did lots of work on v1.0.0 https://github.com/dilame/instagram-private-api/tree/v1.0.0

@thefilmmaking

which methods from source did you implement?

https://github.com/dilame/instagram-private-api/blob/master/src/feeds/tagged-media.feed.ts become https://github.com/dilame/instagram-private-api/blob/v1.0.0/src/feeds/tag.feed.ts

[heychazza]

@dilame can you fix registering?

[dilame]

@dilame can you fix registering?

I don't need it. Why can't you do that?

[heychazza]

@dilame you’re the developer of the project, when we try to use the account register it fails. Lots of others have complained too

[dilame]

@dilame you’re the developer of the project, when we try to use the account register it fails. Lots of others have complained too

This is opensource project, and nobody pays me for working on this. I'm implementing only what i need. I don't need registering. If you need it - feel free to implement it or fix existing, i will accept your PR. Plus i'm not the only maintainer, you could ask someone with Contributor status, @zzarcon for example, but i don't think it's a good idea to ask somebody do your work for you :smile:

[heychazza]

@dilame I was suggesting perhaps fixing as it was already implemented - just broke that’s all.

If it wasn’t already added, I’d understand but it exists.

[dilame]

I was suggesting perhaps fixing as it was already implemented - just broke that’s all.

If it wasn’t already added, I’d understand but it exists.

To be honest i've never even used registration. Somebody implemented it a long time ago, a lot has changed since then. As i know, instagram now requires google safety net tokens in order to register. I don't know how to obtain it.

But,really, if you need it - try to do it by yourself.

[heychazza]

@dilame ah I understand, I’ll look into it - I didn’t mean to give off the impression that you have to do it.

Merely it’s just it was already added, so I thought to look into it as I saw others really wanted this feature too :)

[dilame]

Friends, we need a new name for this library. https://www.npmjs.com/package/instagram-private-api belongs to @huttarichard , but he is not responding emails, so i can't publish this package to npm 😢 Offer your options for the library name. The requirement - it should be free on npmjs.com

[picoderman]

@dilame Maybe igpapi?

[zzarcon]

ig-private-client ?

[thefilmmaking]

ig-private-api ?

[huttarichard]

Guys Im probably in different timezone :) but what do you need about npm? How so you cannot publish?

po 15. 4. 2019 v 5:56 odesílatel Dmitry notifications@github.com napsal:

Friends, we need a new name for this library. https://www.npmjs.com/package/instagram-private-api belongs to @huttarichard https://github.com/huttarichard , but he is not responding emails, so i can't publish this package to npm 😢 Offer your options for the library name. The requirement - it should be free on npmjs.com

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dilame/instagram-private-api/issues/702#issuecomment-483099294, or mute the thread https://github.com/notifications/unsubscribe-auth/ABubdNcgzeFnLM5f8qh2accrXNRy7Klaks5vg_hjgaJpZM4cgdjS .

[dilame]

Hello, @huttarichard , glad to see you! :) Travis CI auto-deployment broke down long ago, some problems with NPM token, i emailed you a few times about this, but you didn't answer. I have no other way to publish the package to npm because only you have access. If you could help somehow it would be nice.

[huttarichard]

I made you maintainer long time ago :)

On 15 Apr 2019, at 14:35, Dmitry notifications@github.com wrote:

Hello, @huttarichard https://github.com/huttarichard , glad to see you! :) Travis CI auto-deployment broke down long ago, some problems with NPM token, i emailed you a few times about this, but you didn't answer. I have no other way to publish the package to npm because only you have access. If you could help somehow it would be nice.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dilame/instagram-private-api/issues/702#issuecomment-483233394, or mute the thread https://github.com/notifications/unsubscribe-auth/ABubdH4BRCnXbvtZYlg51_NloE1XAOupks5vhHIFgaJpZM4cgdjS.

[dilame]

I made you maintainer long time ago :) … On 15 Apr 2019, at 14:35, Dmitry @.***> wrote: Hello, @huttarichard https://github.com/huttarichard , glad to see you! :) Travis CI auto-deployment broke down long ago, some problems with NPM token, i emailed you a few times about this, but you didn't answer. I have no other way to publish the package to npm because only you have access. If you could help somehow it would be nice. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#702 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ABubdH4BRCnXbvtZYlg51_NloE1XAOupks5vhHIFgaJpZM4cgdjS.

Really... I didn't noticed it, can't understand how. Npm didn't send me an alert, i just checked in my inbox. You too :) Anyway, thank you, users will be happy to install latest version from npm!

[heychazza]

Is it possible to have add support for getting username => user id?

[SebastainMisas]

I hope you can update the documentation for the new typescript version when it's ready :) great work

[dilame]

I hope you can update the documentation for the new typescript version when it's ready :) great work

I hope too 😄 But, to be honest, i'm not sure I can do that, because there are only 24 hours in my day. I hope i could provide at least code examples, but i would be soooo happy if someone help me with docs.

[SebastainMisas]

^^ can anyone help with the typescript docs? hit up @dilame. I'm willing to compensate anyone that will help.

[huttarichard]

nice job with 1.0.0 👍 love this release! Big thanks to @dilame and community for effort. Im watching npm for opensource projects build with it! Btw in case you need my help with something just @ mention me, email will let me know.