From the xep-0045: http://xmpp.org/extensions/xep-0045.html#enter-history
It seems that user can only get room history messages when he is joining the room. For example, user can get 20 messages when joining the room.
But after joined the room, If user want more history messages, there seems no way achieve this.
Any ideas?
I have resolve this issue. There are two solutions:
1. Current ejabberd MAM does not support MAM MUC. But there is a branch that you can use for testing. Remember it is not public released yet.
https://github.com/processone/ejabberd/blob/master/src/mod_mam.erl
write a module to hook the user_send_packet, in the hook, store the MUC messagess in SQL. Then provide a http API to request the MUC messages. From the client side point of view, I use the HTTP API to query the MUC history messages.
refer to this thread:
ejabberd MAM does not work for MUC
Related
Is it possible to do a dynamic subscription with spring WebSocket?
We have a multi-tenancy application and the need is to send messages to a group of users within the tenant. I am currently achieving his with a user-specific queue, but this is not effective as we are adding the same message to all the user's queues. The problem with using a tenant-specific topic is from the client any one case subscribe to the same topic once the topic name is known.
Any ideas or help will be appreciated.
You could use a Topic and subscribe it from every user (frontend).
Then you send the Messages for a group of Users to this Topic.
So every subscribed user get Updates broadcasted.
Perhaps this Tutorial would help.
https://www.dariawan.com/tutorials/spring/spring-boot-websocket-stomp-tutorial/
To make it more secure, you can add the SessionIDs to virtual groups, so its safe only specific users are allowed to subscribe the Topic.
Zendesk Support is a world-class site full of useful information. But after searching for, and reading, lots of articles I still have some very basic questions:
We run a travel site that takes bookings. We have a need to organise our emails so that everyone can easily find every email regarding an individual booking, both incoming and outgoing. (And later we would add other channels like chat and WhatsApp).
It seems to me that Zendesk Support would do this job well. But throughout the Zendesk site there only seems to be talk of using Support for problems.
1) I assume that it would also be good for bookings, is that right?
Ok, so we set up Zendesk and start using it. A client then writes to our chosen email address (we will retain and use one of our domain email addresses) and Zendesk Support automatically starts a thread and sends us an email to tell us about the new thread. We then open the Zendesk console, and find the thread.
2) To reply by email to the client we then write a comment in the Zendesk console - is that right?
3) And presumably our email system gets a copy of the comment?
4) What happens to our actual email system? - We will be doing everything in Zendesk, so all the usual maintenance of our email inbox is not being done - marking as read, cancelling stuff, moving to other folders and so on. How do people manage the inbox on the original email server?
Thanks for any help on this.
Zendesk Support is a world-class site full of useful information. But
after searching for, and reading, lots of articles I still have some
very basic questions:
We run a travel site that takes bookings. We have a need to organise
our emails so that everyone can easily find every email regarding an
individual booking, both incoming and outgoing. (And later we would
add other channels like chat and WhatsApp).
It seems to me that Zendesk Support would do this job well. But
throughout the Zendesk site there only seems to be talk of using
Support for problems.
You are correct in that a plurality if not majority of use cases are
for customer contact centers which usually focus on addressing issues
after they arise. At the same time, I know Zendesk is used for a
variety of other use cases including in your space.
1) I assume that it would also be good for bookings, is that right?
Ok, so we set up Zendesk and start using it. A client then writes to
our chosen email address (we will retain and use one of our domain
email addresses) and Zendesk Support automatically starts a thread and
sends us an email to tell us about the new thread. We then open the
Zendesk console, and find the thread.
Yep, that sounds correct. Details on the mechanism for configuring
the Support Address and redirecting messages to Zendesk can be found
here.
2) To reply by email to the client we then write a comment in the Zendesk > console - is that right?
While it is possible to work from an inbox, Yes, the main emphasis is
on working in the Zendesk agent console.
3) And presumably our email system gets a copy of the comment?
I would suggest to check out some of the articles provided by Zendesk
about email. forwarding, SPF, email archiving
4) What happens to our actual email system? - We will be doing
everything in Zendesk, so all the usual maintenance of our email inbox
is not being done - marking as read, cancelling stuff, moving to other
folders and so on. How do people manage the inbox on the original
email server? Thanks for any help on this.
Basically, Zendesk will be used by agents to respond to communications
and guide the interactions, and the email box can be considered as
operational in directing emails as needed. Separately you can
configure email archiving as linked above.
Depending on what system you're using, Gmail has a built in connector
described here, details on Exchange here, or something else here.
What do you want the interaction to look like between it and Zendesk
and what does your current operation look like compared to motivation
for using something like Zendesk?
Using the Smooch API, I am trying to obtain all of the messages sent to my Facebook appid in the past few minutes or hours.
The Get Messages REST method does exactly what I need, except for that it only returns messages from a particular appUserId. This isn't useful unless you already know what users have sent you messages. I cannot use a webhook as the application resides behind a corporate firewall. Opening the firewall to connections that originate from the outside is not an option (even with white-listing).
Is there a way to invoke the Get Messages REST method such that it will ignore the appUserId filter? Perhaps some sort of wildcard character?
GET {{url}}/{{apiVersion}}/apps/{{appId}}/appusers/{{appUserId}}/messages
Unfortunately you do need to have the appUserId (or userId) on hand in order to query user messages.
Webhooks are a pretty essential part of building a Smooch integration. If you can't receive them through your firewall, then you might consider building an intermediary service outside of your corporate network for receiving Smooch webhooks. For each webhook event you receive it would either:
Forward it through a secure tunnel into your coprorate network
Store the appUserId (or the whole event) in its own database, and provide a secure endpoint that allows your corporate network service to query that data
I'm curious to know more about your use case, e.g which Smooch channels are you integrating? With more details I might be able to improve this answer.
#alavers We would like to leverage nearly every messaging integration you offer.
#alavers You may want to consider providing a Get Messages variant that is better suited for use within a corporate firewall environment. An excellent example is the http long poll implementation provided by APIs such Amazon's SQS API. Their receiveMessage method waits for up to the specified time period but returns as soon as a message is received. This provides nearly the same performance of a webhook but eliminates the need for a customer to open their corporate firewall to connections that originate from outside the corporation. Most IT departments will approve connections that originate from within the corporation, but permitting connections that originate from the outside becomes a very difficult sell.
I know that using MQTT topics devices can subscribe to them. But is there any way that a IoT device can send some message to a target IoT device (by device id or something) without using a topic or is there any standard topic for this scenario?
There is no way to communicate without a topic, but you can create a topic for any purpose. So typically if you wanted to send a message to another client, you would publish it somewhere in the hierarchy of topics to which that client is subscribed.
That could be as simple as something like device/12345/inbound or whatever you prefer. And because topics can have hierarchy, in addition to whatever detail you put in the body, you can also encode categorization of your message into the topic, much as RESTful APIs often do in a URL.
A good reason for using target-specific (or owner-account-specific) topics is that the most easy solutions for MQTT security compartmentalization are topic-scope.
I am using mosquitto mqtt client.
For example, you have users that publish and subscribe to topics. The topic actually correlates to a REsT endpoint.
Scenario 1 (typical pub/sub usage)
UserA subscribes to topic /device/123/meta
UserB publishes some data to topic /device/123/meta
by definition, this publish is broadcasted out to the subscribers
we have a script subscribed to /devices/# which knows how to save the payload for the topic /device/123/meta when it receives publish'ed data. This data is saved to the database.
Scenario 2
Someone updates data /device/123/meta via a ReST interface (or a direct DB update, the key is it's not a MQTT publish).
database is updated
a publish message is sent to the MQTT broker so that all subscribers get the updates as a payload
Scenario 2 is what I'm trying to wrap my head around. This creates a nasty feedback loop. When internal messages are broadcasted out, my script to deal with publish events from users can't differentiate between publish events originating from a 3rd party user or an internal publish event only meant to broadcast out some data (with no saving of data needed).
How should I handle this? The MQTT message is very simplistic and I'm not finding anything I can base logic off of. I'm trying to explore using the origin somehow, but no luck this far. I realize I can write plugins, but this is quite the task for mosquitto.
There is no way to distinguish where a message originated from the subscriber at a pure MQTT protocol level. Part of the point of a pub/sub protocol is to decouple publishers from subscribers.
The most portable way to do this would be to add a flag to the actual message payload to indicate that message originated from somewhere other than the actual device.
Or assuming the message is being published as a result a trigger in the database have the trigger check if the incoming message actually changed the database stored value, if the incoming messages matches the existing state of the DB then there is no need to republish it.
Mosquitto's plugin mechanism is currently only for writing authentication and authorisation solutions, but the JavaScript mosca or Java HiveMQ brokers support plugins that may be able to do what you want.