Hi Matthew,

Not sure if we had opportunity to meet and talk on one of the FOSDEMs already. In any case it is good to talk to fellow XMPP developer.

We could do what you are asking about but I cannot comment on the specific costs yet. This depends on the extend of the work, especially related to mentioning custom push service. What you mean by this exactly - custom push service? Siskin (and Tigase server) already support Push through APN. If your server (Prosody) supports push through APN too, then it might be just a matter of adding your Push certificates. Please comment.

Other questions which come to my mind.

1. Would the custom Siskin client be open source, if so, what license?
2. What about long-term maintenance (and costs) - new versions, bug fixes etc....
3. Would you publish information that the iOS client is Siskin based and provided by Tigase? Yes, we need some publicity too.

Please give us some ideas and/or suggestions on how you see this all organized.

Artur

Hi Artur,

On Tue, 2 Jun 2020, 20:53 Artur Hefczyc, sales@tigase.net wrote:

Hi Matthew,

Not sure if we had opportunity to meet and talk on one of the FOSDEMs already. In any case it is good to talk to fellow XMPP developer.

Yes indeed, many years ago :)

We could do what you are asking about but I cannot comment on the specific

costs yet. This depends on the extend of the work, especially related to mentioning custom push service. What you mean by this exactly - custom push service? Siskin (and Tigase server) already support Push through APN. If your server (Prosody) supports push through APN too, then it might be just a matter of adding your Push certificates. Please comment.

Yes, I'd plan to push directly to APNS from my own server. I have a similar setup for Android already.

Though, I believe you guys also have some custom protocols in this area. I'm planning to read through the spec and understand exactly what that entails.

Other questions which come to my mind.

1. Would the custom Siskin client be open source, if so, what license?

It would be fully open-source, I'm fine with GPL (this would match the Android client, and Siskin's current license). I believe there would also need to be an appropriate exception allowing for upload to the app store. For example this is what the Nextcloud folks did: https://github.com/nextcloud/ios/blob/master/COPYING.iOS

All the Snikket-related projects are at https://github.com/snikket-im

1. What about long-term maintenance (and costs) - new versions, bug fixes etc....

Rather than produce a hard fork ideally I'd like to keep the Snikket changes fairly minimal so that I can rebase them on top of Siskin as it evolves. If I need assistance with that, I'd reach out.

This also implies that I'd like to see as many changes upstreamed into Siskin as possible (obviously not the rebranding, but any additional XMPP features and UX work). It is possible that in some cases we may have different ideas about the best UI/UX (it is not an exact science) and such differences would have to be maintained, but hopefully they would be few.

1. Would you publish information that the iOS client is Siskin based and provided by Tigase? Yes, we need some publicity too.

Absolutely! One goal of this project is to help grow and sustain the XMPP ecosystem, and that includes giving credit where it is due :)

Please give us some ideas and/or suggestions on how you see this all organized.

This is a very new project, so I'm open to ideas and learning the best approach as we go.

I can say that for the Android client, I have a good relationship with the Conversations author, Daniel. He assisted in the rebranding and implementing the invite link handling (Siskin already has this!) on a contract basis. So far I haven't needed any further support, but it's likely that I will want to add some features in the future that will require his help again. Daniel has access to the snikket-android repo on Github, but it is primarily me maintaining it right now and preparing releases (simply based on merging code from new Conversations releases).

Regards, Matthew

Hi Artur,

A quick addition. I'm working on submitting an application for Snikket to https://mozilla.org/builders

If accepted it would provide a source of funding for the iOS development. If not accepted, I will source funds from elsewhere.

The application submission requires team members to be listed, and I'd like to list someone from Tigase (Andrzej?) who would be working on the project (July-August, not necessarily full time). Let me know if this would be ok.

If not, or if we're not accepted, nothing lost :)

Regards, Matthew

P.S. the submission deadline is coming up soon, so a quick yes/no on this point would be great!

{cut >>>}On Wed, 3 Jun 2020 at 11:44, Tigase Support sales@tigase.net wrote:

Hi Artur,

On Tue, 2 Jun 2020, 20:53 Artur Hefczyc, sales@tigase.net wrote:

Hi Matthew,

Not sure if we had opportunity to meet and talk on one of the FOSDEMs already. In any case it is good to talk to fellow XMPP developer.

Yes indeed, many years ago :)

We could do what you are asking about but I cannot comment on the specific costs yet. This depends on the extend of the work, especially related to mentioning custom push service. What you mean by this exactly - custom push service? Siskin (and Tigase server) already support Push through APN. If your server (Prosody) supports push through APN too, then it might be just a matter of adding your Push certificates. Please comment.

Yes, I'd plan to push directly to APNS from my own server. I have a similar setup for Android already.

Though, I believe you guys also have some custom protocols in this area. I'm planning to read through the spec and understand exactly what that entails.

Other questions which come to my mind.

1. Would the custom Siskin client be open source, if so, what license?

It would be fully open-source, I'm fine with GPL (this would match the Android client, and Siskin's current license). I believe there would also need to be an appropriate exception allowing for upload to the app store. For example this is what the Nextcloud folks did: https://github.com/nextcloud/ios/blob/master/COPYING.iOS

All the Snikket-related projects are at https://github.com/snikket-im

1. What about long-term maintenance (and costs) - new versions, bug fixes etc....

Rather than produce a hard fork ideally I'd like to keep the Snikket changes fairly minimal so that I can rebase them on top of Siskin as it evolves. If I need assistance with that, I'd reach out.

This also implies that I'd like to see as many changes upstreamed into Siskin as possible (obviously not the rebranding, but any additional XMPP features and UX work). It is possible that in some cases we may have different ideas about the best UI/UX (it is not an exact science) and such differences would have to be maintained, but hopefully they would be few.

1. Would you publish information that the iOS client is Siskin based and provided by Tigase? Yes, we need some publicity too.

Absolutely! One goal of this project is to help grow and sustain the XMPP ecosystem, and that includes giving credit where it is due :)

Please give us some ideas and/or suggestions on how you see this all organized.

This is a very new project, so I'm open to ideas and learning the best approach as we go.

I can say that for the Android client, I have a good relationship with the Conversations author, Daniel. He assisted in the rebranding and implementing the invite link handling (Siskin already has this!) on a contract basis. So far I haven't needed any further support, but it's likely that I will want to add some features in the future that will require his help again. Daniel has access to the snikket-android repo on Github, but it is primarily me maintaining it right now and preparing releases (simply based on merging code from new Conversations releases).

Regards, Matthew

In reply to:

Hi Matthew,

Not sure if we had opportunity to meet and talk on one of the FOSDEMs already. In any case it is good to talk to fellow XMPP developer.

We could do what you are asking about but I cannot comment on the specific costs yet. This depends on the extend of the work, especially related to mentioning custom push service. What you mean by this exactly - custom push service? Siskin (and Tigase server) already support Push through APN. If your server (Prosody) supports push through APN too, then it might be just a matter of adding your Push certificates. Please comment.

Other questions which come to my mind.

1. Would the custom Siskin client be open source, if so, what license?
2. What about long-term maintenance (and costs) - new versions, bug fixes etc....
3. Would you publish information that the iOS client is Siskin based and provided by Tigase? Yes, we need some publicity too.

Please give us some ideas and/or suggestions on how you see this all organized.

Artur

You have received this message because you are a participant of the conversation in the issue issue #224. Sincerely yours, YouTrack

{cut}

Yes for adding Andrzej as a team member.

Ok, I am in favor of OK for your requests but I cannot offer hard-commit at the moment. Let's do it and see how it goes.

As for work/cost estimation, I will ask Andrzej to give us some ideas.

Artur

Andrzej, could you please give us some ideas on work estimation for the requested customizations? Just a rough estimation should be good enough.

@wojtek any idea why we lost "related emails" field from the ticket when it was moved from sales to siskin project? Do we need any config in the project in order to keep related emails? Is there any reason for not having related emails field?

any idea why we lost "related emails" field from the ticket when it was moved from sales to siskin project? Do we need any config in the project in order to keep related emails? Is there any reason for not having related emails field?

@kobit IT's because HelpDesk and HS projects are setup as "helpdesk" (see https://www.jetbrains.com/help/youtrack/standalone/Use-YouTrack-as-a-Help-Desk.html#set-up-project) and have additional workflows associated with them, which entails additional fields, in this case it's "related emails". While we could add filed to all projects, I'm not sure we want to attach this workflow to all projects (it shouldn't cause any harm, it basically send latest comment do all 'associated emails').

Hm, I am not sure myself. Maybe it does make sense to add it to public projects for open source code?

Hm, I am not sure myself. Maybe it does make sense to add it to public projects for open source code?

@kobit Well, it's up to you :-)

In general, only projects that are configured with mailbox integration (so helpdesk and helpdesk-sales) will receive any message and will have this field set automatically. The issue arises when ticket is move to different project and we would like to keep notifying users (that started via e-mail). It wasn't set like that before because I was under the impression that the "workflow" was: answer quickly for helpdesk reported issue and if it requires more work create separate issue in dedicated project, which basically nulls problem with moving issues between projects.

@kobit If (for now) it is just about rebranding and push service, then it should be rather a simple thing to do:

• replace colors with alternative colors (assuming that those would be provided - ie. colors to replace purple) (possible some XML changes in assets)
• Tigase logo is used in many places but it is actually a single "bundle" of images so replacing those images should do the trick (no code change)
• replace the list of suggested services to register the account (move the list to separate resource file?)

That would be a day or two.

Then we have:

• update signatures for the application (who would provide certificates for signing the app?)
• new certificates for custom push component
• replace JID of push component
• custom push service (?) - I would need clarification what does that mean. Do we as Tigase give our Tigase Push away? or some new XMPP component needs to be created in a different language? (lua?) With custom push service I have a feeling that it might be good either to give out Tigase Push or just pass the knowledge and create a component in Lua to make it better fit for Prosody.

And without those details, I cannot provide you with an estimate for that part.

Most likely, changing signatures would, updating JID and new certificates should not take longer than a day.

Then we have a custom push component/service which may take up to a week (can be less, can be more, it depends on the answers).

I've just talked with Matthew as he asked me for some details related to the application for Mozilla and he was thinking about using P2 (https://github.com/iNPUTmice/p2) push component from Daniel. It is written in Java as well as ours and has some basic APNs support (I do not know how good is it). I think that basic push functionality could work almost out of the box or within a day or two (if some change would be required).

More advanced features (like pushes for calls, etc.) would require more work, and maybe it would be ready within a week. It basically depends how good existing APNs support is there and if we would keep it or just replace it.

@kobit I have not mentioned our push component to Matthew, but maybe it would be a good idea to let him know that he could integrate it (using Tigase on the push backend). But this is "non-public" component, so I've left that to you.