New Ideas for application development/ identity!

[RonaldColyar]

1. Focus more on the Mobile application development , since the mobile application will be used the most!
2. Create landing page for mobile application(marketing)!
3. Create Notification system(mobile or email)!
4. Develop a clear vision as to how this bond differ from original bond touch ( one that I can think of is the ability avoid paying for multiple different bond devices if you and your lover breaks up)
5. custom notification sounds for different lovers/contacts.

6. CREATE WEB API FOR SENDING LINKS TO SPECIFIC SOUNDS!!

7. Unique bond sound for notifications(our signature).

[FotieMConstant]

@quiet-programmer @Jael-dev you've read this?

[sudo-which-qp]

@FotieMConstant just seeing it now... Will start working on it

[sudo-which-qp]

mainly, this is when we need to talk about getting a UI for the mobile app ready...

[RonaldColyar]

@quiet-programmer check the other issues

[dilanlongla]

I totally buy the idea its a good one

[RonaldColyar]

@quiet-programmer @FotieMConstant @dilanlongla https://stackoverflow.com/questions/11508613/how-does-push-notification-technology-work-on-android

[FotieMConstant]

mainly, this is when we need to talk about getting a UI for the mobile app ready...

I've done some UI/UX I could come up with one.

[FotieMConstant]

Like I was saying @RonaldColyar @quiet-programmer @dilanlongla @Jael-dev how about we work on REST? I think It'd make it easier for us, implementing the mobile and web version. Even if at some point we want to have a client desktop. Would be easy to integrate. Question. Does firebase enable one to pass through a their party application or script, which would be links the front-end and the firebase db? The reason why I want use to work on REST is because I'd like us to have a standard for the data flow. If not the case, I think we can use firebase for Auth and all what not and posgresql or mongodb for the db. That way we can use websockets(for now) for the real time communication (webrtc would be great in the long run I think). And the rest is done through fetching of data etc. Which we will just have to hit the endpoints to get them. Please guys, do let me know so we can start this soon. @quiet-programmer once we are out with this... I'll put all the ideas on a UI design with @RonaldColyar, if he's available for the UI part ... And then we can focus more on the mobile app🙂

[FotieMConstant]

One point I love, which @RonaldColyar raised is ... We should focus on the mobile app because that's what will be mostly used!... That said we should agree and setup the backend well. For the mobile to be good!

[sudo-which-qp]

https://stackoverflow.com/questions/11508613/how-does-push-notification-technology-work-on-android

using Flutter, we actually use Firebase Cloud Messaging for Push Notifications, I think we should finish the REST API first

@FotieMConstant @RonaldColyar

[RonaldColyar]

@quiet-programmer I linked that question above haha

[RonaldColyar]

@FotieMConstant since firebase is a front end, self-authentication. The way we would link someone to a sound is by just using front-end paths. So for example we give them a link like this bond.com/users/fhdhdjd/song1.mp3. And when they get on the page we can take the query parameters and use javascript to fetch this data from fire base database. We search the database for fhdhdjd's song1.mp3 and play it once it's found

[sudo-which-qp]

@FotieMConstant since firebase is a front end, self-authentication. The way we would link someone to a sound is by just using front-end paths. So for example we give them a link like this bond.com/users/fhdhdjd/song1.mp3. And when they get on the page we can take the query parameters and use javascript to fetch this data from fire base database. We search the database for fhdhdjd's song1.mp3 and play it once it's found

for the app or web? @RonaldColyar

[FotieMConstant]

@RonaldColyar yeah, it should b more of web. However this is more in the situation the partner is not connected?

[FotieMConstant]

I think the idea here is to keep them connected in real-time... So like could we try to focus more on that ? Like they listen to the same song onInvite() and if accepted they both can listen together in real time

[FotieMConstant]

What are you thoughts?

[RonaldColyar]

@FotieMConstant @quiet-programmer I was saying like if I wanted to link someone a sound on Facebook. Like a random person, you would send them a link because they aren't a user of the platform. But yeah for other services, they should be connected. But the whole idea bond is to send them sounds and play it for them because in reality most people work jobs and can't open the app at the same time. So I think it would be great just to queue up sounds for them, so when they get on the app(when they have time) they can hear the sounds from their lovers. But also other features where they can join a live session and listen to music together over sockets and stay connected in real-time .

[RonaldColyar]

I get the onInvite idea, but that should be secondary because typically lovers have different schedules

[RonaldColyar]

I feel like the sounds feature will be used a bit more than the streaming together feature

[sudo-which-qp]

Okay I get it now